[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