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


From: Jordi Gutiérrez Hermoso
Subject: Re: [Pkg-octave-devel] Bug#706376: Bug#706376: Bug#706376: Bug#706376: octave: sparse matrix n*2^16
Date: Sat, 15 Jun 2013 21:59:38 -0400

On 15 June 2013 11:00, David Bateman <address@hidden> wrote:

> That a bit of a specious argument. "Because we can't solve problem B we
> shouldn't solve problem A". Taking this argument to the absurd this
> shouldn't work either
>
> n = 2^16;
> s = sparse (1:n,1:n,1);
> t = s * s;

You're strawmanning me.

I'm saying the real problem is that we assume linear indexing works
for all matrix types, including sparse matrices. I claim that this is
the real problem. We can patch around this problem by avoiding linear
indexing, but this is just treating the symptoms, not the disease.
While I don't deny that we can make some progress masking the
symptoms, the disease itself should also be treated somehow.

> So essentially you're saying that sparse matrices with
> 32-bit indexing and numel larger than 2^31 are useless!!

I'm saying that they will fail in other unexpected ways, and we
shouln't mask symptoms. By all means, avoiding calling numel whenever
possible, but don't mask symptoms. Should numel or similar actually
get called for such sparse matrices, at the very least there should be
a warning. I would prefer if the warning occurred at the time that the
sparse matrix is created, until we can fix the actual underlying
problem.

> A lot of attention was made in the sparse implementation to not rely
> either on linear indexing or the value of numel to avoid this issue.

It's great you avoided that, but the users of the sparse matrix type
might not immediately think of avoiding it.

- Jordi G. H.


reply via email to

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