From help-octave-request at bevo dot che dot wisc dot edu Sun Dec 22 13:03:30 2002
Subject: Re: octave and image processing
From: Al Niessner <Al dot Niessner at jpl dot nasa dot gov>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: help-octave mailing list <help-octave at bevo dot che dot wisc dot edu>
Date: 22 Dec 2002 14:04:08 -0500

On Sat, 2002-12-21 at 13:00, John W. Eaton wrote:
> On 21-Dec-2002, Al Niessner <Al dot Niessner at jpl dot nasa dot gov> wrote:
> 
> | 3) The mutability of the data in an image
> |   a) in-place operations allowed via .oct files only
> |   b) nominal -- as done normally in octave
> 
> | [...]
> 
> | Lastly, there
> | is (3). This is a little more difficult. It would allow reference to be
> | passed within .oct files causing the original data to change. However,
> | the user would have to explicitly choose this option and accept all the
> | pitfalls that come with it.
> 
> Unfortunately(?) you can't do this without some other changes to
> Octave.  There are a couple of levels of reference counting.  One is
> in the Matrix object itself and the other is in the octave_value
> object.  If you look at the octave_scalar object, you will see that it
> is just a container for a double (or complex) number.  Neither of
> those objects implements reference counting, but Octave does not allow
> functions to modify scalar arguments either.  For example, if you do
> something like
> 
>   function f (x) x = 2; end
>   x = 1;
>   f (x)
>   x
> 
> you will find that x still has a value of 1 after the function.  The
> reference counting you need to modify is the overall reference
> counting scheme for octave_value objects.  You can't change that by
> defining a new sub-type like octave_image.
> 
> Sorry, but what you want to do will require some fundamental changes
> to the way Octave works.  You mentioned before that you didn't want to
> do that because it would introduce some maintenance problems for you.
> That's only true if you make the modifications and they are not
> included in the "standard" Octave sources, but if we can come up with
> a reasonable way to introduce "pass-by-reference" semantics for
> functions in Octave, I'd be happy to try to implement that (or help
> you do it).  The primary problem that I see is that whatever we come
> up with will probably not be compatible with whatever the MathWorks
> does for Matlab if they choose to implement similar functionality.
> 
> jwe

I may have missed something, but it appears as though the
octave_value_list is an extension of Array.h and it depends on
Array::make_unique() to do the reference counting and copy which is a
shallow copy -- as it should be. Hence, the example I sent should be
sufficient for the doing the job I need done.

Remember that I want the reference handling only in OCT-files and not
M-files because I do not want to change the grammar and thus the
interpreter.

I am still working on how to make it safe for Array to be treated as a
being passed by reference rather than by value into an OCT-file, but I
have the beginnings of an idea. I make the ability to ignore the
reference counting in Array<T> private to that class -- a boolean field.
I would then add an inner class that had access to that private field.
The constructor of the inner class would then take the Array<T> instance
in question in a parameter.

Something akin to:

class Array<T>
{
public:
   class ReferenceBehavior
   {
      private:
         Array<T> &ref;
      public:
         ReferenceBehavior (Array<T> &changeToRef) : ref(changeToRef)
         { ref.ignoreReferenceCounting = true }
         ~ReferenceBehavior() { ref.ignoreReferenceCounting = false }
   }
private:
   boolean ignoreReferenceCounting; // default should be false
}

In this way the user would then do something like this:

#include <octave/oct.h>

DEFUN_DLD (testDynamicFunc, args, orgs, "Test Dynamic Functions.")
{
  Image test1 = args(0).image_value();

  {
     Array<T>::ReferenceBehavior behaviorAdjuster = 
                           Array<T>::ReferenceBehavior(test1);

     ... do operations with test1 behaving as though it was passed by
reference...
  } // the ending of the scope make test1 pass by value again

  return octave_value(test1);
}

Now, this is not perfect by any stretch, but I think you can see where I
am going with it -- hopefully. It allows for some new types to be
handled as references in OCT-files, but the original octave types should
go unaffected. Like I said, I have to give the above stuff more thought
to get right, but its a start anyway. Looking at it, ReferenceBehavior
should probably be an inner class to Image and ignoreReferenceCounting
should be protected in Array<T> so that Image can modify it. That way,
someone cannot use this mechanism with Matrix or something.


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
-------------------------------------------------------------