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

[Michael D. Godfrey]

On 04/29/2013 03:12 PM, Jordi Gutiérrez Hermoso 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.
>
> 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.
>
> 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.
>
> 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.
>
> - Jordi G. H.
Will 64bit Octave "automatically" fix this?

Michael

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