Re: in-place operation semantics,

[Jaroslav Hajek]

On Sun, Dec 6, 2009 at 2:52 AM, Naveen Garg <address@hidden> wrote:
> Does octave also allow this sort of thing ?
> http://blogs.mathworks.com/loren/2007/03/22/in-place-operations-on-data/

Currently, there is no such optimization across function calls except
for user-defined subsasgn class methods (which I think is a
particularly important case). The computed assignment operators now
operate in-place in the most common cases; unary operators ! and - can
also reuse their argument in-place if it's a temporary expression.
Going much further here makes little sense without JIT compilation.
For functions, I'd like to contribute a more general mechanism, but
not before 3.4.

Note also this sentence from the above link:
"# There is no interface for the in-place operations via MEX-files."

This is exactly the opposite of what I'd like to do. I consider it
much more important to enable this optimization for compiled (OCT)
functions which normally aim for high performance.

> fortran_vec() is nice, but it would be even nicer if it could be a global,
> exported function and it took a pointer to octave values, and such a pointer
> could be obtained.

I don't understand what you propose. Try to be more specific.

> I think lack of pass by reference and pointers is a serious handicap against
> scipy.

It's a tradeoff. The argument passing mechanism of Matlab/Octave is a
big fat plus considering the simplicity of the language, because you
never need to worry about mutable/immutable objects and their
ownership.
In Octave, I can look at a segment of code and I immediately tell
whether a certain variable is changed in this segment. This is not
possible in Python - you need to know what the individual functions
do, which arguments they can change and which they can't.
In Octave, everything behaves *as if* values are always copied;
everything else are optimizations. In Python/NumPy, it's the user who
needs to worry about array ownership; on the other hand, NumPy is much
more powerful regarding memory efficiency.

Let me illustrate some of the differences on a simple (and a bit
artificial) example:
say you're writing a function that takes an array of values and return
the top thirty percent values.

function y = top30percent (x)
  n = numel (x);
  piv = nth_element (x, 0.7*n); # nth_element exists in 3.3.50+
  y = x(x >= piv);
endfunction

It's simple, and it will be simple even in NumPy:

def top30percent(x):
  piv = nth_element (x, int(0.7*n)); # let's say this exists in NumPy
  return x[x >= piv];

 But after using it in practice you realize that the x dataset will be
often already sorted from prior processing, so you decide for a simple
optimization:

function y = top30percent (x)
  n = numel (x);
  if (issorted (x))
    y = x(round(0.7*n):n);
  else
   piv = nth_element (x, round(0.7*n)); # nth_element exists in 3.3.50+
   y = x(x >= piv);
  endif
endfunction

This is perfectly OK in Octave - it will take less time and also
possibly save memory, because in the sorted case you'll return a
shared copy. But what to do in Python?

def top30percent(x):
  n = x.size;
  if issorted (x):  # let's say this exists
    return x[0:int(0.7*n)-1];
  else:
    piv = nth_element (x, int(0.7*n)); # let's say this exists in NumPy
    return x[x >= piv];

Good? No, it's *bad*:

y = top30percent (x);
my = mean (y); y(y > 5*my) = my; #clear outliers.

The problem is that after the Python version is called, it may or may
not be safe to modify the array. So, in NumPy, the last assignment
will overwrite also x, but only if it was sorted. It's really a bad
idea to write functions like this. You can force the copy inside
top30percent, at the cost that it may be useless. A practical solution
in NumPy would probably be to provide an extra output argument, or
maybe create two separate functions.

In Octave, there are no such issues. You always own your results;
Octave handles the rest.

> I am using the mingw port of octave, and am able to load dll's that can then
> call functions in .oct files compiled with mkoctfile.
> I am having to rewrap functions such as set_global_value and
> get_global_value.
> Couldn't liboctave behave more like python dlls and export more functions
> for the mingw version?
> Maybe I am missing something, and they are already exported somewhere, but
> which files do they end up in ?

These functions have nothing to do with liboctave, they're interpreter
stuff, hence should be in liboctinterp.

best regards (and sorry for the lengthy discussion)

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz