octave-maintainers
[Top][All Lists]
Advanced

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

Re: Re-implementation of inline functions


From: David Bateman
Subject: Re: Re-implementation of inline functions
Date: Wed, 4 Aug 2004 21:11:17 +0200
User-agent: Mutt/1.4.1i

According to John W. Eaton <address@hidden> (on 08/04/04):
> I also don't have a copy of the latest release of Matlab, so I am
> going by the docs from the MathWorks web site.  This syntax is
> metioned in the description of function handles, so I believe it
> returns a function handle with no name, or a name like "<anonymous
> function>" or something, though I don't know precisely since there is
> no example for that in the docs.

Yeah I read them a bit closer to. The fact is that the only place you 
see the name of the function handle is with print_raw. So if we are
to treat this syntax like inline it makes sense to me that print_raw
prints the formula. Then we don't care about the name of the function
handle.

> 
> | 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.
> 
> Yes, you would probably want to cache the extra information.  I was
> just suggesting that after you scan the args to inline and decide what
> variable names to use, you could construct a string to eval to create
> the inline function part.  Then a call like
> 
>   inline ('x^2')
> 
> could create a function handle by doing the equivalent of
> 
>   fh = eval ("@ ( x ) x^2", error_catching_code_here);
> 
> So an inlined function is just a function handle with some extra
> attributes.  And the inline() function itself does some tricky magic
> that is probably best avoided.

Vectorize, argnames, etc would have to work on the function handle, so
would probably be best of as built-in even if inline is a dot-m file.
Not sure if it is worth seperateing it in that case, but might be
better to keep all of the code in one place and thus leave Finline in
ov-fcn-handle.cc..



>  Rules like:
> 
>   The input argument to the inline function is automatically
>   determined by searching expr for an isolated lower case alphabetic
>   character, other than i or j, that is not part of a word formed from
>   several alphabetic characters.  If no such character exists, x is
>   used.  If the character is not unique, the one closest to x is
>   used.  If two characters are found, the one later in the alphabet is
>   chosen.
> 
> seem bad to me.  Perhaps I'm a bit slow today, but what is the
> intended meaning of "if the character is not unique", and why is it
> "closest to x" in one case and "later in the alphabet" in the other?

This is pretty much what I felt. But if we don't implement something
someone will try (ie assume arg is "x"), someone will try inline("1+t")
and wonder why it didn't work...
> 
> | This brings up the question of how does the function print_raw look like
> | for the case of "@ (ARG_LIST) EXPR"..
> 
> Do you mean what should the printed representation of an anonymous
> function handle be?  I think it should just print
> 
>   <anonymous function handle>
> 
> or similar.

See my argument above...

> 
> | 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?
> 
> If you mean
> 
>   function y = f (x) y = 1+x; endfunction
>   g = @ (f) 1+f
> 
> then I think f is an argument to the function.  It would be the same
> as if you had done
> 
>   function y = f (x) y = 1+x; endfunction
>   function z = h (f) z = 1+f; endfunction
>   g = @h

Yes I figured it out by reading the docs on the matlab website a bit more
closely...

D.

-- 
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



reply via email to

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