On a related note the tech support at MATLAB is very responsive. Every time I have had an issue they get back to me quickly, and I feel like the follow up and really fix bugs.
On a related note the tech support at MATLAB is very responsive. Every time I have had an issue they get back to me quickly, and I feel like the follow up and really fix bugs.
A = X; A(1) = A(1);
Then one can evilly edit A in-place in a mex file without accidentally editing other arrays like X. However, the docs tell us never to edit arrays from input arguments in place, so a future version of Matlab could be cleverer and still break things. I wish their mex API would provide a supported way to edit things in-place. Native Matlab code does allow inplace editing: A = fun(A);
If function fun is defined that way too, A can be altered in-place by native matlab code, but not (officially) by mex functions.Actually Matlab's pass by value is one of its best properties (as a language). This is how functions work in math and is much easier to reason about.
I really dislike Julia's pass by reference semantics. Even if it enables better performance.
A = plus_diag(A, x); % Using [1] below
Adds a vector x onto the diagonal elements of a huge matrix A. In old versions of Matlab, 2*huge memory would temporarily be allocated. Now the memory usage doesn't increase: A is altered in place. This optimization happens automatically when Matlab notices it can be done. The code has to be in a function though, not run from the command-line or a script.[1] http://homepages.inf.ed.ac.uk/imurray2/code/imurray-matlab/p...
It is not a characteristic of the function `plus_diag`. The function itself is completely pure.
It would be nice to take advantage of the same idea in mex code where possible. For example an API function that indicates if it is safe to over-write an input array and return it as the corresponding output or not. I don't think Mathworks currently provide documented and future-safe means to do so however. (If one controls all the code, updating things in-place is possible in practice if careful, using the A(1)=A(1); trick I gave in a parent post. Such code is just not guaranteed to be future-proof.)
[1] http://blogs.mathworks.com/loren/2007/03/22/in-place-operati...
In [1]: a = [1, 2, 3]
In [2]: b = a
In [3]: a is b
Out[3]: True
In [4]: b = a[:]
In [5]: a is b
Out[5]: False
Usually this kind of "optimization" is done to avoid copying large ammounts of data in memory, but as you said, unless it's widesepread knowledge or explicitly stated, it can lead to some confusing situations/bugs.It is only because they were using a buggy dll (which for non-matlab users, is custom native code that matlab calls against using a FFI), that the expected semantics of matlab were violated.