Re: oct function question

[Paul Kienzle]

On Oct 1, 2006, at 5:23 PM, Anand Patil wrote:

> Thanks for your responses, Paul and Søren.
>
> > Not sure I understand your question.  The matrix object owns the
> > data and there is no way to create a new matrix object which points
> > to existing data.  Two matrix objects can point to the same data,
> > but the data is copied if either are modified.
>
>
> What I'd ultimately like to do is pass an output matrix into an oct  
> function, manipulate it as a C array, and have the changes persist  
> when the oct function terminates without any data copying at all (data  
> in matrices are passed into oct functions by reference, correct?).  
> Here's a bare-bones example:
>
> ----------------------oct function:--------------------------
>
> DEFUN_DLD(change_matrix, args, , "Changes all the elements of a 2X2  
> matrix to 1")
> {
>    double* A = args(0).matrix_value().<<fortran_vec, data, etc.>>()
>    for(int i=0; i<4; i++) A[i] = 1.0;
> }
>
> -------------------------Desired functioning in  
> Octave:-------------------------------
>
> octave:1> A = zeros(2);
> octave:2> change_matrix(A)
>
> A =
>
>    1  1
>    1  1
>
> octave:3>
> ----------------------------------------------------------------------- 
> ----
>
> Could you recommend a best method for doing that?

Octave semantics are explicitly copy-on-write for matrices.  This is  
much easier for the programmer to get right, though it is less  
efficient in speed and memory.  The fact that this behaviour is  
compatible with Matlab means that it won't change.

Python allows some objects to be updated in place.  It took less than  
two days for my end users to be bitten by this.  The error was deep in  
a library.  I could have written the library so that it forced a copy  
of the array, but this would have been inefficient in the usual case.   
I've seen this in other places as well. In some Rogue Wave code I've  
worked with the author called copy() methods at odd and unnecessary  
places so that he didn't have to think about who else is referencing  
the memory.

It might work to have copy on write as the default, but be able to  
explicitly mark an array or an operation as modifiable in place in the  
rare case that the extra efficiency is necessary.  Updating the entire  
octave infrastructure to implement, test and maintain this for the long  
term would be a daunting task, and I doubt patches to do this would be  
welcomed.

You could probably implement your own octave type which has the  
semantics that you are looking for, but it would revert to copy on  
write whenever you called a function which doesn't know about it.

- Paul