Re: Reducing memory by emulating IDL's temporary() function

[Jaroslav Hajek]

On Thu, Apr 24, 2008 at 10:51 PM, Judd Storrs <address@hidden> wrote:
>
> On Thu, Apr 24, 2008 at 4:09 PM, John W. Eaton <address@hidden>
> wrote:
>
>
> > Given this definition, what happens if you write
> >
> >  A = something;
> >  A = temporary ("A") + A
>
> octave:1> A = [1,2,3,4];
> octave:2> A = temporary ("A") + A
> error: `A' undefined near line 2 column 23
> error: evaluating binary operator `+' near line 2, column 21
>  error: evaluating assignment expression near line 2, column 3
> octave:2> A = [1,2,3,4];
> octave:3> A = A + temporary ("A")
> A =
>
>    2   4   6   8
>
> In the last case A = A + temporary("A") takes the same amount of memory as A
> = A + A
>
> Both cases fail in IDL:
>
> IDL> A = [1,2,3,4]
> IDL> B = A + temporary(A)
> % Variable is undefined: A.
> % Execution halted at: $MAIN$
> IDL> A = [1,2,3,4]
> IDL> B = temporary(A) + A
>  % Variable is undefined: A.
> % Execution halted at: $MAIN$
> IDL>
>
> Failing for both cases is probably the correct behavior.
>
> I don't think generating these sorts of errors is a problem. I tend to think
> of using temporary() in IDL as a performance tweak similar to vectorizing
> loops.
>
>
> > Also, since you are accessing the symbol table, your code will not
> > work with Octave 3.1 since the symbol table code in Octave has been
> > completely rewritten since 3.0 in order to support Matlab compatible
> > classes.
> >
>
> Thanks for the heads up. I'll look at the development version.
>


I was thinking about this too, based on John's suggestion about a month ago:
http://www.nabble.com/Octave-and-GSOC%272008-tt15692994.html#a15692994

My conclusions:

1. there can be an explicit means of "give a value and deallocate".
Instead of creating a stand-alone `temporary', however, I suggest
extending `clear' to return the cleared value when called with nargout
= 1.

2. It would be nice if Octave recognized the situation with expressions like
`A = func (A, B)'. This raises the question, however, what should
happen when exception
occurs inside `func'. Normally, if an exception occurs in evaluating
rhs, the lhs is not touched. Implementing a feature that would allow
treating calls `A = func(A)' as "call by reference" would unavoidably
violate this behaviour - the question is how much.
Making `A = f(A)' behave simply like `A = func(clear("A"))' is the
worst - it would result in A often being undefined. Perhaps some extra
reference counter could be added to the octave_value class that would
allow treating a value as "scheduled for deletion" - this would
prevent the underlying octave_base_value from deletion but would not
count when doing make_unique.

tree_simple_assignment::rvalue could then pass the names of duplicate
symbols to other rvalue methods; and tree_index_expression (which I
think is responsible for evaluating functions) would react
appropriately by evaluating arguments, scheduling the duplicate
symbols for deletion, calling the function, and then reacquiring the
symbols if an exception occured.

Either way, the full backward compatibility would necessarily be
broken - if the exception occurs in `func' after A has been modified
inside, then the resulting A will be modified. Is there some way
around that I don't see?

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz