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, 1 Mar 2009 21:10:09 +0100

>
> Well I'm finally somewhere I can write an e-mail from easily, though I
> haven't had the time to reread the thread. The issue I considered in the
> past like this was operations like "speye(n) .^ 0" or "speye(n) ./ 0" where
> the 0.^0 and 0./0 terms of the matrix should create a NaN in the resulting
> matrix I hadn't considered the "speye(n) OP NaN" but didn't and don't yet
> see why it should be different if the NaN is pre-existing rather than
> created by the binary operation, otherwise the NaN values won't propagate
> and in fact might very likely disappear. You seem to think, and have
> convince John that disappearing NaN's are a good thing so I'll try to reread
> the thread and respond again later on.
>

OK, please do. I don't insist that I've done everything correctly, but
I stand firm by the general idea:
Octave should be allowed to use mathematical identities and
simplifications regardless of whether they preserve NaN/Inf behavior.
"scalar*diag (vector)  = diag (scalar*vector)" is a mathematical
identity and that's what Octave uses when calculating the product. The
behavior when scalar is NaN is just a consistent consequence.

There are numerous ubiquitous math formulas and identities that do not
hold when you plug in NaNs and Infs. Horner's scheme for polynomials,
for instance. Or just about everything involving distributivity of
multiplication. The sparse * matrix multiplication. The triangular
division. etc, etc.

That being said, I now see a small flaw in the current behavior. 0/x =
0 is not mathematically right if x is zero, so giving an inconsistent
result in this case (i.e. diagonal matrix / zero) could be justified.
Since there is a warning by default anyway, I don't think it really
matters, but I wouldn't oppose giving a matrix of NaNs in this case. I
think, though, that the current behavior is somewhat more practical
(no memory fill-in).

regards

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