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

[Ed Meyer]

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?


> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20130430/bf73a11e/attachment.html>