From: "John Creighton" <JohnCreighton_@hotmail.com>
Path: news.mathworks.com!newsfeed-00.mathworks.com!webx
Newsgroups: comp.soft-sys.matlab
Subject: Re: growing array in Matlab? (new code)
Message-ID: <ef11420.19@webx.raydaftYaTP>
Date: Fri, 19 Aug 2005 02:18:32 -0400
References: <woodchips-EDAAE9.21275017082005@syrcnyrdrs-01-ge0.nyroc.rr.com> <MPG.1d6e3a12f3c423c98992c@news.mathworks.com> <woodchips-E55FA6.08284918082005@syrcnyrdrs-02-ge0.nyroc.rr.com> <woodchips-7262EC.11380018082005@syrcnyrdrs-03-ge0.nyroc.rr.com> <de2hup$qgu$1@ruby.cit.cornell.edu>
Lines: 66
NNTP-Posting-Host: 69.199.155.76
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Xref: news.mathworks.com comp.soft-sys.matlab:296841


Stephen Vavasis wrote:
>
>
> Dear Loren and John,
>
> This is a feature of Matlab that is new to me and is very neat! It
> seems to
> me that this technique (storing data in a function handle of a
> nested
> function) may provide a workaround better than global variables to
> bypass
> the "call by value" limitation of Matlab. Perhaps this trick will
> make it
> possible to write objects that are efficient implementations of
> data
> structures like heaps, in which some of the methods are supposed to
> update
> the underlying data structure.
>
> -- Steve
>
>
> "John D'Errico" <woodchips@rochester.rr.com> wrote in message
>
news:woodchips-7262EC.11380018082005@syrcnyrdrs-03-ge0.nyroc.rr.com.
> ..
>> In article
>>
<woodchips-E55FA6.08284918082005@syrcnyrdrs-02-ge0.nyroc.rr.com>
,
>> John D'Errico <woodchips@rochester.rr.com> wrote:
>>
>>> In article
<MPG.1d6e3a12f3c423c98992c@news.mathworks.com>,
>>> Loren Shure <loren.shure@mathworks.com> wrote:
>>>
>>> > I have not tried anything here and don't know the
performance
>>> > implications, but instead of persistent, what if you
made your
> grow
>>> > array function return a handle to a nested function
which
> stored the
>>> > data there? That way, you could have more than
instance.
> Just a
>>> > thought...
>>> >
>> It is an interesting idea. The code is below. It also
>> runs in linear time, as did my last attempt. But it is
>> also sadly twice as slow as was that last code. The
>> profile tool suggests that 47% of the time was spent
>> in function overhead. This explains where the doubled
>> time came from.
>>
>> John
>>
>
>
I haven't read everything in this thread by what I gather is the data
is stored in a persistent variable and not a function handle. The
function handle just provides a key to that data. I'll read more to
see if I understand this right. I don't see anything wrong with the
global variable approach I will provide more information about this
in my next post.