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

[Ed Meyer]

On Mon, Apr 29, 2013 at 12:12 PM, Jordi Gutiérrez Hermoso <
jordigh at octave.org> wrote:

> On 29 April 2013 14:50, Ed Meyer <eem2314 at gmail.com> wrote:
> > I'm not proposing using anything but octave_idx_type for indexing or
> > changing the return type of numel() - I just question why numel() is
> > used for sparse matrices. It should be irrelevant for anything but
> > ccs2full().
>
> The numel function is just one example where this sparse matrix with
> big dimensions broke. Sparse matrices this large can still break in
> other ways. Furthermore, what do you propose to do if numel is called
> for sparse matrices, despite your suggestion to not call it for sparse
> matrices? A lot of code out there already assumes that you can treat a
> sparse matrix like any other matrix. I don't think numel is to blame.
>

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.


> Another way I can think of would be that A(idx) would also break if
> idx is greater than the maximum index size. We would have to introduce
> special rules to handle that for sparse matrices of large dimensions.
>

Here again, why would you ever want A(idx) for a sparse matrix?


>
> The problem isn't the storage size, it's the index size, which is why
> for other matrices Octave's error message says out of memory or index
> too big. I really don't see a way around this other than introducing a
> special index type for sparse matrices, and I don't see this as hugely
> useful. It also looks 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?


>
> But if you insist on doing this, don't let me discourage you. If you
> can figure out a consistent behaviour that doesn't break current code,
> you write the patch, and all tests pass, I'll happily apply it.
>

this doesn't seem to be a burning issue so I'll shut up


-- 
Ed Meyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20130429/c9edfadf/attachment.html>