[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave and image processing

From: Paul Kienzle
Subject: Re: octave and image processing
Date: Mon, 23 Dec 2002 08:55:30 -0500
User-agent: Mutt/

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

On Sun, Dec 22, 2002 at 02:04:08PM -0500, Al Niessner wrote:
> On Sat, 2002-12-21 at 13:00, John W. Eaton wrote:
> > On 21-Dec-2002, Al Niessner <address@hidden> 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:
> How to fund new projects:
> Subscription information:
> -------------------------------------------------------------

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

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]