help-octave
[Top][All Lists]
Advanced

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

Re: Realtime cost of call by value


From: Tomer Altman
Subject: Re: Realtime cost of call by value
Date: Sat, 1 Nov 2003 07:39:36 +0000 (UTC)

Hi John,

Please find my comments interspersed below:

On Oct 31, 2003 at 7:53pm, John W. Eaton wrote:

jwe >Date: Fri, 31 Oct 2003 19:53:10 -0600
jwe >From: John W. Eaton <address@hidden>
jwe >To: address@hidden
jwe >Cc: help-octave <address@hidden>
jwe >Subject: Re: Realtime cost of call by value
jwe >
jwe >On 31-Oct-2003, John W. Eaton <address@hidden> wrote:
jwe >
jwe >| On 31-Oct-2003, address@hidden <address@hidden> wrote:
jwe >| 
jwe >| | This would allow for both to live side-by-side, harmoniously ( I
jwe >| | believe ). ;-)
jwe >| 
jwe >| Not even close.  [...]
jwe >
jwe >After rereading this message, I think it may have come across as a bit
jwe >rude, which was not my intent.

No worries. I realize that coming in as a newbie & making brash
suggestions was going to get me into a peck of trouble. ;-)

jwe >
jwe >I would be interested in a way to pass arguments by reference, but it
jwe >must not be the default.  Here is a (half-baked) proposal to think
jwe >about.
jwe >
jwe >Similar to C++, I think the notion of a reference argument should be a
jwe >property of the function definition, not the code that calls the
jwe >function.  So we would write something like
jwe >
jwe >  function F (reference A)
jwe >    ...
jwe >  endfunction
jwe >
jwe >or perhaps, if you prefer concise and cryptic
jwe >
jwe >  function F (&A)
jwe >    ...
jwe >  endfunction

Brilliant! I like the idea of keeping the referencing a property of
the function arguments. It avoids any kind of 'persistence' of the
"state" of a given variable within a function. No need to cast or
other nonsense.

jwe >
jwe >to declare that A is passed by reference for all calls to F rather
jwe >than something like
jwe >
jwe >  function F (A)
jwe >    ...
jwe >  endfunction
jwe >
jwe >  F (X)
jwe >  F (reference (X))
jwe >
jwe >to say that X is passed by reference for just some calls and not
jwe >others.
jwe >
jwe >Given the above definition of F, you could expect
jwe >
jwe >  F (X);     # OK, pass X by reference.  If F changes A, X also changes.
jwe >  F (1);     # ERROR, reference to constant.
jwe >  F (X+1);   # ERROR, reference to temporary.
jwe >  F (X(1));  # ERROR, reference to temporary.

My Scheme evaluation instincts are nagging me, but I'm fighting
back. :-) This looks good. Makes complete sense that the onus is on
the programmger to define their large data
(structure/array/cell-array) to be a bound variable.

jwe >
jwe >If you write
jwe >
jwe >  Y = X;
jwe >  F (X);
jwe >
jwe >and F changes A, only X changes, not Y.  Given the current
jwe >implementation of Octave, a copy will be forced at the point of the
jwe >function call, but not at the Y = X statement (that just increments an
jwe >internal reference count).
jwe >
jwe >I'm not sure what syntax we should use, but a unary & as above would
jwe >be one possibility that would not be incompatible with Matlab syntax
jwe >(at least currently).

I like the unary operator idea, but something more akin to your C++
instincts with using "references" makes much more sense to me, and is
"self-documenting". I think a Octave newbie with no C/C++ background
would sooner frob "ref" or "reference" than the 'cryptic' ampersand. :-)

jwe >
jwe >We could also introduce a way to make one variable a reference to
jwe >another apart from argument lists.  Something like
jwe >
jwe >  reference A = B;
jwe >
jwe >or perhaps
jwe >
jwe >  &A = B;  
jwe >
jwe >would cause A and B to share the same value in memory.  If A changes,
jwe >so does B, or if B changes, so does A.  If you did something like
jwe >
jwe >  C = B;
jwe >  reference A = B;
jwe >
jwe >then changed A, only A and B would change, not C.

No! This would just lead to ambiguity & mess. Your idea of leaving it
to the function implementors to state where their code needs to pass
by reference is genious. So clean & hits exactly the copy-down
inefficiency that this thread was originally going after. Let's not
open up the pointer can-of-worms too much here. :-)

jwe >
jwe >Again, making this work will require some additional reference
jwe >counting trickery in Octave as currently the first assignment doesn't
jwe >actually force a copy, it just increments an internal reference count.
jwe >So in the above, we would actually force a copy at the point of the
jwe >reference declaration.  But that is just an implementation detail.
jwe >What I'm most interested in now is what the syntax and semantics
jwe >should be, not precisely how it will have to be implemented.
jwe >
jwe >Comments?
jwe >
jwe >jwe
jwe >

That's it for now. Thanks for the thoughts, John!

~Tomer



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



reply via email to

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