Re: diagonal matrices specializations

[Jaroslav Hajek]

On Thu, Dec 4, 2008 at 6:13 PM, John W. Eaton <address@hidden> wrote:
> On  4-Dec-2008, Jaroslav Hajek wrote:
>
> | OK, I've pushed the patches.
> |
> | Rationale: as in the first mail.
> |
> | Summary of changes:
> |
> | Rectangular diagonal matrices are now special objects.
> |
> | [...]
> |
> | i.e. a 38x, resp. 100x speed-up (will increase with n).
> |
> | TODO:
> | 1. special printing/saving of diagonal & permutation matrices
> | 2. make "balance" benefit from the changes
> | 3. I'm sure there's a lot of stuff I forgot.
> | 4. Sparse code is mostly untouched. When dealing with diagonal &
> | permutation matrices as sparse, the performance hit is much smaller
> | (not by an order, but a constant factor). As I don't work with sparse
> | matrices much, I'd appreciate advice about what interactions would be
> | beneficial to implement (e.g., diagonal-sparse multiplication etc).
>
> I think this is a good change and the performance improvements are
> impressive.  However, I see the following problem:
>
>  octave:1> x = diag ([1,2,3,4]);
>  octave:2> save foo.dat x
>  octave:3> load foo.dat
>  error: octave_base_value::load_ascii(): wrong type argument `diagonal matrix'
>  error: load: trouble reading ascii file `foo.dat'
>  error: load: reading file foo.dat
>
> Until this is fixed, I can't make a new snapshot, because this
> represents a regression from previous versions and will likely be
> noticed immediately by more than a few people who try to use the new
> snapshot...
>
> jwe
>

OK, this is bad.
Currently, octave_base_diag::save_ascii simply densifies the matrix
and calls save_ascii on the dense instance. Apparently the saving
process is more complicated than I thought. Shame on me not to have
tried it - I'll fix it.

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