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: Bug#706376: octave: spars


From: Jordi Gutiérrez Hermoso
Subject: Re: [Pkg-octave-devel] Bug#706376: Bug#706376: Bug#706376: octave: sparse matrix n*2^16
Date: Tue, 30 Apr 2013 13:09:40 -0400

On 30 April 2013 12:56, Ed Meyer <address@hidden> wrote:
>
>
> 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?

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.


reply via email to

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