[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave and image processing
From: |
Al Niessner |
Subject: |
Re: octave and image processing |
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 <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 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 <=
- Re: octave and image processing, Paul Kienzle, 2002/12/23
- Re: octave and image processing, Albert F. Niessner, 2002/12/23
- Re: octave and image processing, Paul Kienzle, 2002/12/25