Re: octave and image processing

[Albert F. Niessner]

On Mon, 2002-12-23 at 08:55, Paul Kienzle wrote:
> There are a couple of reasons I'm interested in by-reference semantics
> in liboctave.  One is that I have some code using Rogue Wave that I want to
> convert so that it can run without Rogue Wave.  Rogue Wave uses reference
> semantics, and the conversion will be easier if I do not have to change
> the semantics of the array classes.  The other reason is the problem that
> Doug Eck had a couple of years ago, which IIRC is that the loop he was 
> running spent 40% of its time in allocation/deallocation of the returned
> matrix from a matrix-matrix multiplication.  Perhaps this is a bad example
> because matrix multiplication cannot be done in place, but things such
> as fft could benefit from knowing that the matrix operation is in place.
> 
> Paul Kienzle
> address@hidden
> 
> <snip>

The only way to add by-reference semantics to octave is to extend the
grammar to include a new symbol which would indicate a pass by reference
('&' if you wanted to be C like). This would, however, reduce the
compatibility with Matlab since they do not currently support
by-reference syntax or semantics -- that I know of.

I do not think that the FFT can benefit from in-place operations either
since in many instances you are going from a real matrix to a complex
matrix. Hence, you always need to create a new array because of how real
and complex are defined.

My desire to restrict the by-reference to 'image' was to allow matrices
to remain self consistent throughout octave. I think it is very error
prone to have a mixed method for treating parameter passing without
grammar support, but in some cases it is a necessary evil. That is why I
was suggesting that both the developer and user must agree to live with
this evil -- in my case, the developer and user are the same. This would
mean that the developer would have to pretend as though octave was
behaving normally, but the user could allow the developer to use
resources a little more efficiently in specific instances. For example:

#include <octave/oct.h>

DEFUN_DLD (testDynamicFunc, args, orgs, "Test Dynamic Functions.")
{
  Matrix test1 = args(0).matrix_value();
  ByReferenceBehavior reference(test1); // Will set back to by-value
                                        // during destruction of
                                        // 'reference'. It may do
                                        // nothing if the user has
                                        // defined this instance to be
                                        // by-value only.

  for (int r = 0 ; r < test1.rows() ; r++)
    for (int c = 0 ; c < test1.cols() ; c++)
      {
        test1(r,c) = test1(r,c)*2.0;
      }

  return octave_value(test1); // have to return it since it may be
                              // by-value and by-reference
}

Now, the developer is saying that if the user does not mind, he would
like the input matrix to be handled by-reference and not by-value. If
the user did not agree and set a flag for the input to by-value-only,
then the above code will make a copy and modify the copy if the
reference count is greater than 1. This way the user can define which
kind of pain to live with.

Note that M-files would be written the same way since the result of 

x = [ 1 2 3 4] ; x = testDynamicFunc(x)

is the same in either case. It is just that it took less resources in
the by-reference case. Of course, op= should do nothing in the case when
this.rep == this.rep.

Where it gets evil is in this case:

function a = mfunc (x) a = testDynamicFunc(x) ; x = x + 10;  a = x;
endfunction;

Now the user will get a different result if they allow by-reference than
if they use the standard by-value. The only way to fix this is to extend
the grammar. I do not think that the grammar should be extended, but
rather the types which allow you to do by-reference should be limited.
Now, I have been calling it 'image'. If we are include the case of
external program interfaces, then maybe it should be called
'ref-matrix'. In this case, the problems become easier to identify
because they are restricted to a particular type.

I would then say that the semantics of by-reference are limited to a
particular type or subtype. The type or subtype can only be created when
the data is read from the disk or from a specific call (see
http://www.octave.org/mailing-lists/help-octave/2002/1194 -- the added
functions portion). All operations will exist for the type or subtype
except that the return type is always of its type or subtype with
complex suffices or prefaces as necessary. The semantics of the the
by-reference are that the developer, with the users consent, may choose
to treat any input parameter of the type or subtype defined above as
by-reference. Otherwise, all inputs will be by-value.

Notice that I do not suggest having functions for being able to change
the by-reference allowance. This allows the user to be confident that
his choice at creation time is fixed -- the developer cannot change it.
Also, the old OCT-files should still work even when the user allows the
developer to handle the type or subtype by reference because the
developer never asks for it to be by-reference.

Thank you everyone for all of the input. It is helping me to work out
the detail of how I am going to implement this.

Al Niessner




-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------