octave-maintainers
[Top][All Lists]
Advanced

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

Re: saveing/loading symbol table of annymous functions


From: David Bateman
Subject: Re: saveing/loading symbol table of annymous functions
Date: Wed, 18 Apr 2007 00:43:00 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

John W. Eaton wrote:
> On 11-Apr-2007, David Bateman wrote:
> 
> | John W. Eaton wrote:
> | > I'm not sure why we were duplicating the data for a function directly
> | > in the tree_anon_fcn_handle class, so I've checked in the following
> | > change.  Now the tree_anon_fcn_handle object just contains an
> | > octave_user_function object that contains the parameter list, function
> | > body, return list, and symbol table.
> | >
> | > The octave_fcn_handle class has an octave_value object that contains
> | > the function.  You can extract a pointer to the user function object
> | > and then get the symbol table from there using the new
> | > octave_user_function::sym_tab method.  Does that give you everything
> | > you need to write the load/save functions for anonymous function
> | > handles?
> | >
> | > Thanks,
> | >
> | > jwe
> | >
> | >   
> | Ok, I took a quick look at how to go about saving and then reloading the
> | local symbol table of a function handle, and have implemented it for the
> | case of "save {-text|-binary|-hdf5}" in the attached patch, including
> | unit test code. I treated the fact that for
> | 
> | a = 2;
> | f = @(x) = a+x;
> | f(1)
> | save -text test.mat f
> | 
> | the local symbol table of "f" after the evaluation "f(1)" has two
> | undefined symbol records "__retval__" and "x" by excluding undefined
> | symbol records when saving anonymous function handles.
> | 
> | I also tried to handle backwards compatibility by only saving the symbol
> | table if needed. Therefore
> | 
> | g = @(x) 2 * x;
> | save -text test.mat g
> | 
> | can be saved if this patch is applied and read by older versions of
> | octave. The reverse is also true. However, anonymous function handles
> | such as "f" above were never saved correct as the symbol table wasn't
> | saved. So there is no backward compatibility in that case. To do this
> | for the binary type I included the length of the symbol table in the
> | function name like "@<anonymous> 2" if the symbol table has two
> | elements. For text files I added a keyword "length" and the hdf5 files
> | added an attribute "SYMBOL_TABLE" with the length of the symbol table.
> 
> I'm not too concerned about backward compatibility here since I don't
> think loading and saving function handles ever worked properly in the
> past.  But I don't see that the extra information can cause trouble,
> so please check in this patch.
> 
> Thanks,
> 
> jwe
> 

I hesitate to check it in just yet, as in the process of figuring out
how matlab saves function handles, it also saves information on the path
to the non anonymous function handles.

However, I have a problem in that  the matlab function handle is of the form

handle -> object/class ->  string (matlabroot)
                       ->  string (seperator)
                       ->  string (sentinel)
                       ->  object/class (function handle workspace)

The object is the format matlab uses to save classes and is just a
special form of a structure when it is saved. So implementing matlab
load/saving of function handles needs at least a partial implementation
of matlab classes, or at least a way of treating them in mat-files. This
issue has stopped me from looking at the other issue of saving the path
to the non anonymous function handles in octave native formats..

D.


reply via email to

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