Re: About diagonal matrices

[Jaroslav Hajek]

On Fri, Feb 20, 2009 at 5:07 PM, José Luis García Pallero
<address@hidden> wrote:
> Hi,
> 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?
>

The element-by-element versions all produce full matrices, because
that is the general case for result. This is obvious for + and -; .*
and .^ could produce diagonal matrices but I didn't do it for
consistency - diagonal matrices just behave as full matrices when used
in element-by-element operation. There's actually a slight difference
if multiplied by NaN:
NaN .* diag will be a matrix of NaNs while NaN * diag will still be
diagonal (analogously to how sparse matrices behave).
This is chosen deliberately so that the user has some invariants to
work with, i.e. x * diag is *always* diagonal, while x .* diag is
*always* full.

As for the mappers, I specialized just a few of them that are likely
to be used on sparse matrices, like abs, real, imag and conj. sqrt is
also a good suggestion.

cheers

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