Re: type handling bug?

[Michael Creel]

On Tue, May 26, 2009 at 3:45 PM, Jaroslav Hajek <address@hidden> wrote:
> 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

Your response just goes to show that an informed decision was made
here. That's usually the case with Octave, I believe. I wasn't trying
to argue in favor of the opposite behavior - I was just pointing out
that overemphasis on compatibility _can_ have a downside, and that in
any event, the blame/credit does not go to the Mathworks.

RC3 is working fine for me - passes all tests except 2 expected failures.

Cheers, M.