[Pkg-octave-devel] Bug#706376: Bug#706376: octave: sparse matrix n*2^16
Ed Meyer
eem2314 at gmail.com
Mon Apr 29 18:50:12 UTC 2013
On Mon, Apr 29, 2013 at 11:07 AM, Jordi Gutiérrez Hermoso <
jordigh at octave.org> wrote:
> On 29 April 2013 14:00, Jordi Gutiérrez Hermoso <jordigh at octave.org>
> wrote:
> > And yes, sparse matrices can be indexed by a single index instead of
> > two, like any other matrix. Internally in Octave's source, the
> > assumption that a single index of octave_idx_type is available is used
> > throughout.
>
> The specific case where this fails in this instance is octave_idx_type
> dim_vector::numel (), which is obtained simply by multiplying each of
> the dimensions of the matrix, even for sparse matrices (this is unlike
> nnz, so a workaround just for trace.m would be to use nnz instead of
> numel, but I think this would still leave some pretty broken sparse
> matrices lying around with other problems).
>
> We would have to change numel () to use some other type that can hold
> the result of a larger size, but this is a pretty fundamental function
> in Octave. The overall assumption is that you can linearly index up to
> numel (). Every place that calls this function would need to be
> checked to see what happens if we change its return type to be some
> special bigint.
>
> - Jordi G. H.
>
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().
Rather than restrict the size of sparse matrices I think it would make more
sense
to fix problems like this as they come up so that sparse storage is used as
it
was intended - to reduce storage & op count.
--
Ed Meyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20130429/4d7fcd5e/attachment.html>
More information about the Pkg-octave-devel
mailing list