[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: |
Fri, 20 Feb 2009 17:51:57 +0100 |
On Fri, Feb 20, 2009 at 5:45 PM, John W. Eaton <address@hidden> wrote:
> On 20-Feb-2009, José Luis García Pallero wrote:
>
> | Playing with the new diag() function in octave 3.1.52 I can see some
> | extrange behaviour (or I don't understand some particular cases). For
> | example, for the matrix
> | a = diag([2 3 4])
> |
> | This is a diagonal matrix: typeinfo(a) -> diagonal matrix
> | But if I add a scalar: typeinfo(4+a) -> matrix
> | If I multiply by a scalar: typeinfo(4*a) -> diagonal matrix
> | But if I multiply by a scalar in element-by-element form: typeinfo(4.*a) ->
> | matrix
> | If I divide by a scalar in element-by-element form: typeinfo(4./a) -> matrix
> | For a power operation: typeinfo(a^2) -> diagonal matrix
> | But element-by-element: typeinfo(a.^2) -> matrix
> | For functions: typeinfo(sqrt(a)) -> matrix (the same for sin(), cos(), etc.)
> |
> | Has any reason for this behaviour?
>
> A definition is needed in each case for oprators that receive special
> treatment. So I guess some have just not been implemented yet.
>
> But I think there are also some bugs. Shouldn't the following return
> full matrices with the zero elements replaced by NaN (or -0, in the
> case of dividing by -Inf)?
>
> diag ([1,2,3]) / 0
> diag ([1,2,3]) / NaN
> diag ([1,2,3]) / -Inf
> diag ([1,2,3]) * NaN
> diag ([1,2,3]) * Inf
>
I think it's better in the current manner. I don't like the idea that
the memory can suddenly explode just because the multiplier happened
to be Inf. Right now, scalar * diag gives invariantly diag. This is
somewhat analogous to how sparse matrices behave.
> etc. Maybe the simplest way to implement this would be to do
> something like
>
> tmp = 0 / scalar_value;
> if (tmp != 0 || lo_ieee_signbit (signbit))
> convert to full matrix, replacing zeros with tmp;
>
> in these methods.
>
> If you want to discuss this further, then maybe we should move the
> discussion to the maintainers list.
>
> jwe
>
--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz