Re: Re-implementation of inline functions

[David Bateman]

According to John W. Eaton <address@hidden> (on 08/03/04):
> On  3-Aug-2004, David Bateman <address@hidden> wrote:
> 
> | Coming back to the Octave 3.0 ToDo list, the things on it that haven't
> | yet been addressed are
> | 
> |   * some support for MPI
> 
> There is some work happening on this now.

Ok...

> 
> |   * sparse matrices
> 
> Not sure about this.  My impression is that the current sparse code in
> octave-forge would need some significant cleanup to be included in the
> core Octave and that we might want to switch to using UMFPACK instead
> of SuperLU (see for example the notes by Paul Kienzle here:
> http://www.octave.org/mailing-lists/octave-maintainers/2002/219).

Also read the speed comparisions on the site

http://www.cise.ufl.edu/research/sparse/umfpack

UMFPACK is significantly faster than SuperLU. The site above also contains
the latest v4.3 of UMFPACK.

As the code is octave-forge has the distinction of existing and working 
already with octave, its probably the best starting point. Perhaps the
way forward here is to be very very specific about what you don't like 
about Andy's package, and I'm sure he'd be happy to change those things
if that made it acceptable for an inclusion without octave itself.

> 
> |   * finish implementation of cell arrays and struct arrays:
> |       -- cell(idx) = [] to delete elements
> |       -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
> |       -- allow [x{:}] = f (...) to work
> |       -- and other little details like this...
> 
> I've done some work on some of these problems but have not had time to
> finish them.  The third item is a bit tricky and may require some
> changes to the interface of the octave_value::subsasgn method, so this
> is a priority for me if we are going to try to minimize internal
> interface changes for the 3.x series.

Yeah, the third one is a pain since it works on the rvalue where all the
other changes are to the lvalue.

The first one seems pretty easy to me as the change is isolated to
the '(' case of subsref for cell arrays, and examples of how to 
treat this case already exist for NDArrays.

> | As I don't understand all that needs to be done for private functions
> | yet,
> 
> I think private functions are very similar to nested functions but
> to support them properly will require some changes to the
> file lookup code (the stuff in liboctave/pathsearch.cc).

I'm trying to get my head around this problem, and will sure get there
eventually. But would be happy if you have any further pointers or
even code :-)

> | I thought I'd attack the question of inline functions and see
> | what I could do. There is already a reasonable implementation within
> | octave-forge, but it has the disadvantage that it defines as many user
> | defined functions in the symbol table as there are inline functions,
> | and can implement the argnames and vectorize functions in a matlab
> | compatiable manner.
> 
> Shouldn't an inline function be more like a function handle?  The
> latest Matlab release now has this syntax for anonymous function
> handles:
> 
>   @ ( ARG_LIST ) EXPR

The implementation I sent treats inline functions as function handles.
See that is_function_handle returns true. Now that you made the changes
to the octave_fcn_handle class I should probably make the octave_fcn_inline
class inherit from octave_fcn_handle.

However I haven't implemented the syntax

@ ( ARG_LIST ) EXPR

I don't have the latest release of Matlab and so not sure how this syntax 
is treated. Is it an inline function or is it a function handle? Also is
the presence of the "( )" what makes the difference between this and a
normal function handle?

> Given the rest of the language it is not terribly surprising that
> this is so limited, but I think it would have been better if EXPR
> could be some block of statements.
> 
> Along with the new way of invoking a function through a handle of
> 
>   function_handle ( PARAM_LIST )
> 
> isn't this more or less the same as an inline function?  I'm not sure
> why both are included in the language, except that inline functions
> already existed in earlier versions of Matlab.
> 
> In any case, if we implement the above, couldn't inline just be a
> special case of an anonymous function handle?  Would anything but the
> class name need to be different ("inline function" or whatever
> vs. "function handle")?  I suppose the inline function itself (the one
> you call to create an inline function object) would still have the job
> of deciding what arguments to handle as arguments, but wouldn't that
> be easily handled by a call to eval if we have already implemented the
> new "@ ( ARG_LIST ) EXPR" syntax?

Yes, inline could be a special case of function handles in this case.
However, we'd need someway of specifying that the function handle 
points to a real physical function or to an inlined expression. We'd also
need to adapt the function handle class to include a few extra privates
to allow the function formula and argnames to work correctly.

This brings up the question of how does the function print_raw look like
for the case of "@ (ARG_LIST) EXPR"..

Also what happens in the case

octave:1> function y = f (x), y = 1+x; endfunction
octave:2> g = @(f) "1+f"

Is the function handle an inlined function with a variable "f" or is
it a function handle to the function f?

> | I also included all of the missing functions such as vectorize and
> | argnames that were missing. The only missing feature is the extraction
> | of the argument name from a single argument call to "inline", as what
> | matlab does seems a bit dumb to me. Also, as fsolve hasn't been
> | adapted to allow function handles, and perhaps other functions, you
> | can't yet do something fsolve(inline("1-x"),0).
> 
> Yes, these things need to be fixed.  If inline returns something that
> is essentially the same as an anonymous function handle, then we
> should only have to handle two cases (function name as a string and
> function handle) rather than three (inline as well as the other two).

There would only be two cases in any case. That is

        if (args(0).is_function_handle())
          fsolve_fcn = args(0).function_value();
        else
          {
            <The other code>
          }

This is because the inline class I wrote already identifies as a function
handle.

If you tell me the specifics of the "@ ( ARG_LIST ) EXPR" usage, I can
rework my patch as a patch against the octave_fcn_handle class within
octave itself.

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary