octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About diagonal matrices


From: Jaroslav Hajek
Subject: Re: About diagonal matrices
Date: Tue, 24 Feb 2009 15:42:41 +0100

On Tue, Feb 24, 2009 at 2:52 PM, Jaroslav Hajek <address@hidden> wrote:
> On Tue, Feb 24, 2009 at 2:44 PM, dbateman <address@hidden> wrote:
>>
>> It's difficult to respond as I'm on a 3G phone. Octave never had this
>> Behavior with sparse matrices until your recent changes.
>
> What, my changes? I don't think I touched sparse matrices in this
> regard. Or are you referring
> to diagonal matrices? Then I'm confused with the rest...
>
>> Try with 3.0.4 and see.
>
> I see in 3.0.4:
>
> NaN * speye (3)
> ans =
>
> Compressed Column Sparse (rows = 3, cols = 3, nnz = 3)
>
>  (1, 1) -> NaN
>  (2, 2) -> NaN
>  (3, 3) -> NaN
>
> speye (3) * [NaN; 1; 1]
>
> ans =
>
>   NaN
>     1
>     1
>
> i.e., exactly what we have now
>
>
>> Even matlab now produces NaN values in recent versions. I still
>> strongly consider the new behavior is wrong
>
> Yes, that's a bug in Matlab, IMHO. Dunno why they did it. Note that
> they didn't do it in the other cases.
>
>

FYI, a quick google search just showed me that there are indeed Matlab
users surprised by the "fixed" behavior:
http://www.mathworks.com/matlabcentral/newsreader/view_thread/242714
(it's the first google hit on query "matlab sparse scalar nan")

I think that in reality, few users notice these problems. So I kind of
imagine that maybe some important customer griped about this and they
fixed it without thinking of consistency. In the future, probably
users will start asking why
sparse([1,NaN]) * sparse([1;0]) gives 1 when NaN * sparse([1;0]) gives
sparse([NaN;NaN]).

At that point, I guess they will have one of the following choices:

1. tell the user to stop buggering as this is a good feature (TM)
2. try "fixing" even the sparse*matrix and sparse*sparse
multiplication. That is unlikely, as it would probably slow down these
operations, which no doubt would make angry much more users. An option
is probably to use some cache mechanism for the "has a NaN" property
and revert to the old algorithm when false.
3. revert this "fix"

now if they do number 2, that's at least an argument for us to try as
well. Though I'd still regard this as a nonsense, because no normal
numerical software does such stupidities.
Meanwhile, I think following them is a bad idea as there's a fairly
good chance of item 3.


cheers

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]