[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
- Re: About diagonal matrices, (continued)
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/22
- Re: About diagonal matrices, John W. Eaton, 2009/02/22
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/22
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/22
- Re: About diagonal matrices, John W. Eaton, 2009/02/22
- Re: About diagonal matrices, John W. Eaton, 2009/02/22
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/22
- Re: About diagonal matrices, dbateman, 2009/02/24
- Re: About diagonal matrices, dbateman, 2009/02/24
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/24
- Re: About diagonal matrices,
Jaroslav Hajek <=
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/21
- Re: About diagonal matrices, Søren Hauberg, 2009/02/21
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/21
- Re: About diagonal matrices, John W. Eaton, 2009/02/21
- Re: About diagonal matrices, John W. Eaton, 2009/02/21
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/22
- Re: About diagonal matrices, dbateman, 2009/02/25
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/25
- Re: About diagonal matrices, dbateman, 2009/02/25
- Re: About diagonal matrices, Jaroslav Hajek, 2009/02/26