octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pkg-octave-devel] Bug#394982: octave2.9: Crashes on "x(:,


From: David Bateman
Subject: Re: [Pkg-octave-devel] Bug#394982: octave2.9: Crashes on "x(:,
Date: Thu, 26 Oct 2006 08:42:45 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Kim Hansen wrote:
> On 10/26/06, David Bateman <address@hidden> wrote:
>>
>> Note that this is still a very bad idea as it reallocates the memory to
>> the sparse matrix and every assignment, even if you size the initial
>> matrix correctly. This is due to the fact that only enough space for the
>> nonzeros is ever created... I'd therefore highly recommended forming
>> vectors of row, col and value and use the sparse function instead. This
>> is discussed in the sparse section of the manual....
> 
> I have just read that section now, it is really a good section. I can
> see that some of my functions should be rewritten to the row,col,value
> style.
> 
> If I append data at the end of a sparse matrix it should be possible
> to extend it without the reallocation, but I can see that is not how
> it works right now. Is that something I could change octave to support
> or is it a limitation from some libraries it would be difficult to
> work around?
> 

Its really really difficult to change. It was a design choice I made
early in the Sparse<T>::assign and Sparse<T>::assign1 functions.
Basically in most cases when you'll add data to this manner to a sparse
matrix it will need to be enlarged. Even if it doesn't need to be
enlarged, there is a good chance that you might add the data in the
middle of the existing elements, so much movement of data would be
needed. So the assign functions just create a new sparse matrix, fill it
from the old and new matrices and be done with it.

Changing would require a complete rewrite of the assign function, and
also I feel won't make much sense unless you also relaxed the
requirement in a sparse column that the elements are sorted, which I
also made to simplify a lot of code.. I personally don't see a reason to
go to this effort when the workaround is fairly simple...

That being said, if you recognize code where there is an assumption that
the elements are ordered, and can relax that assume (I don't mean like
in the * operator where unordered terms are reordered), then gettin rid
of that assumption might make the job of eventually converting the
assign functions easier..

Regards
David


reply via email to

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