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

Jordi Gutiérrez Hermoso jordigh at octave.org
Tue Apr 30 17:09:40 UTC 2013

On 30 April 2013 12:56, Ed Meyer <eem2314 at gmail.com> wrote:
> On Tue, Apr 30, 2013 at 6:37 AM, Jordi Gutiérrez Hermoso
> <jordigh at octave.org> wrote:
>> On 29 April 2013 17:51, Ed Meyer <eem2314 at gmail.com> 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?

Sorry, I was going from memory of a gdb session yesterday. The C++
isempty function ends up calling numel. I really don't see another way
to reliably implement this function.

>> > 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

This seems again like that special indexing type that seems to me like
a lot of boring work.

>> > 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.

> The key is to use the C++ class system to have different implementations
> for each storage format.

This again sounds like support for a special indexing type just for
sparse matrices.

- Jordi G. H.

More information about the Pkg-octave-devel mailing list