On 15 June 2013 11:00, David Bateman <da...@bateman.eu> 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org