|
From: | Paul Kienzle |
Subject: | Re: oct function question |
Date: | Sun, 1 Oct 2006 21:04:48 -0400 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |