diagonal matrices specializations

Jaroslav Hajek highegg at gmail.com
Mon Dec 8 05:47:49 CST 2008


On Thu, Dec 4, 2008 at 6:13 PM, John W. Eaton <jwe at octave.org> 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
>

Hi John,

saving diagonal & permutation matrices to octave's native ascii and
binary formats is now implemented. The format is like this:

# Created by Octave 3.1.51+, Mon Dec 08 12:45:48 2008 CET <hajek at hajek>
# name: a
# type: diagonal matrix
# rows: 4
# columns: 4
1
2
3
4
# name: p
# type: permutation matrix
# size: 4
# orient: r
1
2
3
4

and similarly for binary data.
Saving to HDF5 doesn't work yet. I think I'd appreciate advice here on
how to do things. It appears that Octave stores typeinfo along with
variables in hdf5 format, just as it does in the native formats, and
expects every class to hdf5-saveable.
But isn't the hdf5 format meant to be an export format? In that case,
maybe the optimized matrices should be converted to full before
saving?

regards


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


More information about the Octave-maintainers mailing list