Re: sparse implementation

[David Bateman]

Thomas Weber wrote:
> Hi, 
>
> I have a question about the sparse code. Does it somehow optimize the
> return results?
>
> Using 2.9.8:
>
> ans =  1
> ans =  1
> ans =  1
> ans = 0
>
> So, if A is a 'sensible' sparse matrix, kron returns a sparse matrix,
> otherwise (matrix C), it doesn't. Is this expected behaviour?
>
> Regards
>       Thomas
>
>
>   
This is explained in the manual, where I've spent some time writing a
section of sparse matrices. Although not complete, it gives a lot of
information. In particular in the section "The Return Types of Operators
and Functions", it explains

<quote>
The two basic reasons to use sparse matrices are to reduce the memory
usage and to not have to do calculations on zero elements. The two are
closely related in that the computation time on a sparse matrix operator
or function is roughly linear with the number of non-zero elements.

Therefore, there is a certain density of non-zero elements of a matrix
where it no longer makes sense to store it as a sparse matrix, but rather
as a full matrix. For this reason operators and functions that have a
high probability of returning a full matrix will always return one. For
example adding a scalar constant to a sparse matrix will almost always
make it a full matrix, and so the example

@example
speye(3) + 0
@result{}   1  0  0
  0  1  0
  0  0  1
@end example

returns a full matrix as can be seen. Additionally all sparse functions
test the amount of memory occupied by the sparse matrix to see if the
amount of storage used is larger than the amount used by the full
equivalent. Therefore @code{speye (2) * 1} will return a full matrix as
the memory used is smaller for the full version than the sparse version.

As all of the mixed operators and functions between full and sparse
matrices exist, in general this does not cause any problems. However,
one area where it does cause a problem is where a sparse matrix is
promoted to a full matrix, where subsequent operations would resparsify
the matrix. Such cases are rare, but can be artificially created, for
example @code{(fliplr(speye(3)) + speye(3)) - speye(3)} gives a full
matrix when it should give a sparse one. In general, where such cases
occur, they impose only a small memory penalty.
</quote>

So in short, yes this is the expected behavior...

Regards
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary