Re: type handling bug?

[Jaroslav Hajek]

On Tue, May 26, 2009 at 3:16 PM, Michael Creel <address@hidden> wrote:
> On Tue, May 26, 2009 at 1:17 PM, Søren Hauberg <address@hidden> wrote:
>> tir, 26 05 2009 kl. 13:02 +0200, skrev Levente Torok:
>>> Thanks for the quick response.
>>> This behaviour may be questionable.
>>> It modifies my data hiddenly(!) for the expense of some memory saving.
>>
>> As Jaroslav said: Blame Mathworks.
>
> Hmm, I don't agree with that. One of the arguments in favor of free
> software is the ability to modify programs to make them work the way
> you want them to. The way Octave works here is the choice of the
> Octave developers, not Mathworks. Bug for bug compatibility has its
> costs. I don't give the Mathworks the credit for the great features of
> Octave, so why should I blame them for the questionable or missing
> features?
>

Well, it's not completely unreasonable. It's true that the implicit
data conversions in Matlab (and, hence, Octave) work mostly the other
way around than in other languages: single + double = single, real +
int = int.
One reason is that double is the "default" type for most results. If
single + double = double, it would take a lot of effort to keep your
computation working in single. Also, there's the numeric argument: the
precision of single + double in fact *is* single. So, I'd say that
although it's unusual, it makes a good sense in the Octave context.
real + int = int is a more unfortunate story. I believe the reasoning
is similar: if a is int8, you may expect a+1 to be int8 (but 1 is
double!). But the numeric argument doesn't really work. I don't much
like this choice either, but I prefer compatibility here.

Btw. actually, I think MathWorks deserves the credit for inventing the
Matlab language (though they borrowed a lot from elsewhere).

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz