From maintainers-request at octave dot org Fri Mar 31 02:52:16 2006
Subject: Re: Bi variate to mono variate functions
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: David dot Bateman at motorola dot com
Cc: Anglade Pierre-Matthieu <anglade at gmail dot com>, maintainers@octave.org
Date: Fri, 31 Mar 2006 03:52:07 -0500

On 31-Mar-2006, David Bateman wrote:

| John W. Eaton wrote:
| 
| >On 30-Mar-2006, I wrote:
| >
| >| Inline functions are created using eval_string, which is given
| >| something like
| >| 
| >|   " at (ARGS) EXPRESSION"
| >| 
| >| where EXPRESSION is the argument passed to inline, and ARGS are the
| >| variable names extracted from EXPRESSION.
| >
| >The answer appears to be yes, it would cause an incompatibility,
| >because functions constructed with inline don't seem to pick up
| >unbound variables from the parent context when they are constructed.
| >So we would need a way to limit this feature to actual anonymous
| >functions.
| >
| >jwe
| >
| >
| >  
| >
| John,
| 
| However, the Finline function indentifies all of the args and makes them
| part of the anonymous function handle. That is "inline('x+y+z')" is
| constructed using an anonymous function handle like " at (x,y,z) x +y + z".
| Whereas the case of a fixed value in a user function is more like
| " at (x,y) x + y + z", where in this case "z" is fixed. So in that can we
| can change make_anon_fcn_handle to resolve any arguments that are not in
| the leading parathesis at the time the function handle is defined.

What about the case of

  b = 1;
  f = inline ('a+b', 'a')
  f(1)

which I think produces an error in Matlab.  So I think we still need a
way to skip the new step of providing initial values for symbols when
defining inline functions.  OTOH, this seems to me to be a strange
inconsistency, so maybe it is a bug in Matlab that anonymous and
inline functions behave in fundamentally different ways.  So are there
any bad consequences if Octave returns 2 for the f(1) expression in my
example above?  If there aren't any, then I think it would be simpler
to implement as we wouldn't need the special case for inline functions.

| This 
| should be a relatively easy change, but I don't like touching the parser
| so'd prefer you do it :-)

OK, but I can't promise when I might get time to do it.

jwe