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: Sun, 22 Feb 2009 18:22:45 +0100

On Sun, Feb 22, 2009 at 6:17 PM, Jaroslav Hajek <address@hidden> wrote:
> On Sun, Feb 22, 2009 at 5:07 PM, John W. Eaton <address@hidden> wrote:
>> On 22-Feb-2009, Jaroslav Hajek wrote:
>>
>> | 1. Leave the assumed zeros treatment. Document it (I'm working on this)
>>
>> OK, after seeing your arguments and thinking about it a bit more, I
>> agree that we should do this if
>>
>>  * There is no way for an operation involving a diagonal matrix to
>>    wipe out an existing NaN value.  This is different from what we
>>    have been talking about (generating NaN values with full matrix
>>    operations vs. not generating them at all with a diagonal matrix
>>    becuase the operations are skipped).  If you already have a NaN
>>    value, I think you want to have it propagated through other
>>    calculations.  I can't come up with any examples, and given that
>>    you have apparently already taken care of cases like
>>
>>      diag ([1, 2]) ./ [1, 0; 3, 4]
>>
>>    I assume you thought about this problem.
>>
>
> Well, that's not really true. Consider:
> a = sparse([1,2],[1,1],[1,2],3,3); a * [1; 1; NaN]
> ans =
>
>   1
>   2
>   0
>
> I.e., in a situation where an element of a vector is always ignored
> (due to the sparsity pattern), NaN is also ignored. Was this what you
> were referring to? It's just the assumed zeros problem all again.
> This cannot happen for square diagonal matrices, but can happen for
> rectangular diagonal matrices:
> diag(1:3,3,4) * [1:3,NaN]'
> ans =
>
>   1
>   4
>   9
>
> The situation is really analogous. To say it differently, it's as if
> you did a part of the calculation symbolically; therefore, the invalid
> numerical value (which a NaN is) does not demonstrate itself.
> If you only think about the diagonal and permutation matrices as
> optimizations to full matrix operations, that should otherwise
> preserve their properties, then they're probably not a good idea at
> all.
> I never thought Octave's operations should be regarded as defined
> sequences of floating-point operations, but rather that they should
> deliver approximations to mathematical results in any suitable way.
> If we disagree on this basic point, then that's a fundamental problem
> and in that case, the diagonal & permutation matrices were probably
> not a good idea in the first place.
> If not, then I actually do not understand where the problem is. Again,
> I remind that the situation has been around for ages and is not
> specific to Octave.
>

Btw, I don't think the exceptional values in the IEEE fp standard were
invented to cause such problems and invalidate basic mathematical
truths, like "scalar * diagonal matrix gives a diagonal matrix".
I don't think that NaNs and Infs were ever intended to create a new
kind of arithmetics, more difficult to implement and use. They really
should be just a tool to handle invalid operations in a more graceful
way than a runtime error.


-- 
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]