octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #48686] Copy of columns of the matrix


From: anonymous
Subject: [Octave-bug-tracker] [bug #48686] Copy of columns of the matrix
Date: Wed, 8 Mar 2017 16:23:02 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0

Follow-up Comment #6, bug #48686 (project octave):

Of course, you are right, this is the same bug. I do not have a solution for
the problem of the impossibility of deallocation when the slices are assigned
to a cell array. But I think in the present case there could be a possible
solution. To state the case: when we have 


T(idx)=T(range);


where range is a contiguous range (idx as an arbitrary index vector), then
what happens is that the right-side expression is realized as a slice, and the
reference counter to T is incremented. Then T is going to be modified, so it
has to be allocated again and copied (because of the incremented reference
counter), then the actual values are assigned, at which point the right-side
expression expires and the space originally pointed to by T is deallocated. In
consequence, the whole vector was copied without need. Of course, there are
work-arounds, but the casual octave user will not know what is going on, thus
violating the principle of least surprise.

What could be done is to check in any assignment of a subset of the elements
whether the right-side expression and the left-side expression are referencing
the same object. In this case, either an explicit intermediate object would
have to be allocated and first all elements copied into the intermediate
object and then back into the object to be modified (which is what happens in
T(idx)=T(range)+0;), or (better but closer to the metal) a call to memmove be
emitted (giving just a single copy operation per element). However, I have far
too little knowledge of the internals of octave to be able to judge whether
this is realistic.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48686>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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