octave-maintainers
[Top][All Lists]
Advanced

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

Re: [Pkg-octave-devel] Bug#706376: Bug#706376: octave: sparse matrix n*2


From: Ed Meyer
Subject: Re: [Pkg-octave-devel] Bug#706376: Bug#706376: octave: sparse matrix n*2^16
Date: Tue, 30 Apr 2013 09:56:52 -0700



On Tue, Apr 30, 2013 at 6:37 AM, Jordi Gutiérrez Hermoso <address@hidden> wrote:
On 29 April 2013 17:51, Ed Meyer <address@hidden> wrote:

> I'm not saying numel() is to blame or should be changed, only that I
> see no reason to ever use numel when handling sparse matrices unless
> you are converting it to full in which case the current behavior is
> ok.

Well, look at the current implementation of trace (), in which numel
is a perfectly reasonable function to call. If you don't want to ever
call numel () for sparse matrices, then you would need to rewrite this
function to check for sparsity as well as any other function that
calls numel ().

I don't see numel() used in trace(), nor in diag() which it calls - what am I missing?
 
> Here again, why would you ever want A(idx) for a sparse matrix?

Because this is the only way to do arbitrary indexing, say, indexing
with a logical index:

    n = 2^16;
    A = sprandsym (n, 1e-7);
    idx = A > 0.5;
    A(idx) *= -1;

The alternative to arbitrary indexing is looping.
 
or if octave_idx_type were a class hierarchy with a (row,col) class
in addition to linear indexing 


> I agree that a special index type is the wrong approach; what I'm
> saying is that with sparse matrices you should never run into this
> problem in the first place if you don't try to treat them the same
> as full. Otherwise why have sparse matrices at all?

It is desirable to have sparse matrices behave like ordinary matrices
under most circumstances, such as indexing and when writing the trace
function. Otherwise, you would have to write special code all over the
place to make sure that if the matrix is sparse, you don't linearly
index it nor do you call numel or who knows what other functions that
I haven't thought about yet.

- Jordi G. H.

Not only is it desirable to have sparse and full matrices behave similarly,
I believe the user should not need to be aware of which storage format
is used so functions like eig() would work for either.
The key is to use the C++ class system to have different implementations
for each storage format.

--
Ed Meyer

reply via email to

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