[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sparse logical matrix efficient storage.

From: siko1056
Subject: Re: Sparse logical matrix efficient storage.
Date: Mon, 7 Nov 2016 04:51:52 -0800 (PST)

dariodematties wrote
> Is there a predetermined way of saving sparse logical matrices in octave?

Yes, for example try

>> row = [1,2,3,4];
>> column = [1,2,3,4];
>> value = logical([1,1,1,1]);
>> A = sparse (row,column,value)
>> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        A           4x4                         76  logical
        column      1x4                         32  double
        row         1x4                         32  double
        value       1x4                          4  logical

dariodematties wrote
> I can save sparse matrices in Octave with the predetermined format:
> row,  column, value.
> But for sparse logical the “value” field is redundant.

The internal storage is not (x,y,val), it is the compressed column storage,
see for details. In the example above

A.cols = [0,1,2,3,4] # Cumulative sum of the entries in each column
A.rows = [1,2,3,4]   # The rows indices = [1,1,1,1]   # The nonzero data

this is using 64-bit indices

A.cols = 5 * 8 byte
A.rows = 4 * 8 byte = 4 * 1 byte
           76 byte

dariodematties wrote
> Of course, I could save this information as a (2,n) regular matrix, but
> this method wont allow me to use full method, for example, and Octave wont
> understand that information as a sparse matrix.

This is true. The algorithms are implemented for the internal Sparse format
and not for other vector representations. But the more important question
is, are you facing memory limitations or what makes the redundancy of one
byte per entry so bad?

As a side note, I don't consider this redundancy as so bad at all. To the
Octave interpreter the appearance is always a consistent Sparse matrix using
compressed column storage. But each insertion of removal of values is
expensive, much more expensive than in dense full matrices. Therefore, many
algorithms internally restore the Sparse format in the very end and do have
temporarily zeros in the nonzero entries. See SparseRep::maybe_compress,
implemented in 


View this message in context:
Sent from the Octave - General mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]