octave-maintainers
[Top][All Lists]
Advanced

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

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


From: Jaroslav Hajek
Subject: Re: Reducing memory by emulating IDL's temporary() function
Date: Tue, 29 Apr 2008 22:31:01 +0200

On Tue, Apr 29, 2008 at 9:12 PM, Judd Storrs <address@hidden> wrote:
>
>
>
>
> On Tue, Apr 29, 2008 at 2:17 AM, John W. Eaton <address@hidden>
> wrote:
> >
> > On 25-Apr-2008, Judd Storrs wrote:
> >
> > | On Fri, Apr 25, 2008 at 1:43 AM, Jaroslav Hajek <address@hidden>
> wrote:
> > |
> > | > 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.
> > | >
> > |
> > | One challenge of changing clear like this is that the function form of
> clear
> > | requires a string argument.
> >
> > The "command" form of clear is also passing a character string
> > argument to the internal "clear" function.  The difference is just in
> > the way the command/function is parsed.
> >
> >
> > | The demonstration code I posted also requires a
> > | string also but I considered that a bug in my implementation.
> >
> > Why?  Clear works on variable names in the symbol table, not on
> > values.
>
> The reason I considered it a bug is that I was following the IDL temporary()
> function definition. I'm still mulling it over but the string idea (i.e.
> symbol name instead of value) has really grown on me. A pitfall of the IDL
> model is that you can do things that are completely useless like
>
> A = temporary(B(:))
> A = temporary(temporary(B))
>
> This is silly in IDL because B(:) creates an intermediate copy of B and the
> original B can't be released. The second one is just a waste of time. The
> explicit symbol name approach avoids that mess and even makes attemting it
> look like incompetant coding:
>
> A = clear("B(:)")
> A = clear("clear(\"B\")");
>
> Should we safeguard against clearing a variable that doesn't have a local
> representation? i.e. don't allow clear with return value on a varible that
> is inherited? Think:
>
> function B = test(C)
>   B = clear("A")
> end
>
> --judd
>

presently, clear("A") with A undefined does nothing; in the case above
either "clear" can issue an error itself, or leave the return value
undefined (i.e. return an empty list), which will cause an error
anyway.

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


reply via email to

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