[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/1.2.5.1i |
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
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: http://www.octave.org
> How to fund new projects: http://www.octave.org/funding.html
> Subscription information: http://www.octave.org/archive.html
> -------------------------------------------------------------
-------------------------------------------------------------
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
-------------------------------------------------------------
- octave and image processing, Al Niessner, 2002/12/19
- Re: octave and image processing, Paul Kienzle, 2002/12/19
- octave and image processing, John W. Eaton, 2002/12/20
- Re: octave and image processing, Albert F. Niessner, 2002/12/20
- Re: octave and image processing, Andy Adler, 2002/12/21
- Re: octave and image processing, Al Niessner, 2002/12/21
- Re: octave and image processing, John W. Eaton, 2002/12/21
- Re: octave and image processing, Al Niessner, 2002/12/21
- Re: octave and image processing, Al Niessner, 2002/12/22
- Re: octave and image processing,
Paul Kienzle <=
- Re: octave and image processing, Albert F. Niessner, 2002/12/23
- Re: octave and image processing, Paul Kienzle, 2002/12/25