Re: inline functions in Matlab R14

[David Bateman]

According to John W. Eaton <address@hidden> (on 09/24/04):
> | since how can you tell if "sin" and "y" are functions or not. Even if they
> | aren't when you define the inline function they might be afterwards...
> 
> In Matlab, that is not possible because all functions are either
> built-in or defined in a .m file somewhere in your path.  Although I
> suppose you could modify the path later and a new function would be
> available.  In that case, I don't think it would go back and alter the
> affected inline functions, but if you used the same inline again, this
> time with the external function(s) available, I would expect it to
> change the meaning.  Once again, bad design.  Is it surprising?

Agreed..

> | Another ambiguity is
> | 
> | inline('x+i'), inline('x+j'), inline('x+I'), inline('x+J')
> | 
> | the first two should have i and j ignored. But matlab doesn't define
> | I and J. Also what about the octave built in constants "e" and "E"?
> | Should they also be ignored...
> 
> Ugh.

Completely agreed, so should we also ignore [IJeE] ?

> | The attached patch tries to do something similar to the matlab behaviour.
> | I ignore the octave builtin constants "I", "J", "e" and "E"... John, its
> | up to you if you also want to drop these as potential inline function
> | arguments...
> 
> OK, I applied the patch (sorry I missed it yesterday).  Unfortunately,
> it does not really recognize functions correctly.  What if you do
> 
>   inline ('array_variable(2)')

Yes, that is what I was trying to get at with inline('x(y)'), where
matlab returns

 ans =
 
      Inline function:
      f(x) = y (x)
 
It seems that in fact even the inline version in R12 returns the same
behaviour as R14, so it is unforgivable that Matlab's doc are so out of 
date for inline.

In any case, matlab assumes that [_a-zA-Z][_a-zA-Z0-9]*[\S]*( is a
function always... It doesn't seem to check the symbol table at all
For example

>> x = [1:3];
>> f = inline('x(y)')

f =

     Inline function:
     f(y) = x(y)

>> f(1)
??? Error using ==> inlineeval
Error in inline expression ==> x(y)
??? Undefined function or variable 'x'.

Error in ==> /crm/pacome/Matlab6.1/toolbox/matlab/funfun/@inline/subsref.m
On line 25  ==>     INLINE_OUT_ = inlineeval(INLINE_INPUTS_, 
INLINE_OBJ_.inputExpr, INLINE_OBJ_.expr);


> (i.e., you are defining a function to extract elements from an
> array).  The current version of inline does this:
> 
>   octave:1> inline ('array_variable (2)')
>   ans =
> 
>   f(array) = array_variable (2)
> 
>   octave:2> inline ('arrayvar (2)')
>   ans =
> 
>   f() = arrayvar (2)
> 
> In both cases, Matlab apparently does
> 
>   f(x) = arrayvar (2)
> 
> which also seems wrong.  I have no function called arrayvar defined,
> so it should be recognized as an argument to the function.  So even
> Matlab is not actually looking at what functions are available.  It is
> just using some lame half-parsing rules.  I don't think that can
> possibly work in all cases.  BTW, it appears that your code will
> recognize variable names inside character strings.


If arrayvar isn't available in the inline function, then it can't be
evaluated with subsref in any case, so it has to be passed as an 
argument for this to make sense. Yes

f() = arrayvar (2)

is a bug however, but pretty stupid as it means there are no args to
the inline function...

> Also, what about functions that do not expect arguments.  In Matlab,
> you are not allowed to write
> 
>   eye ()
> 
> to call a function, so you must write the name alone.  In that case,
> you might write a wrapper function as inline like this:
> 
>   inline ('eye + 3')
> 
> but again, the current version of inline recognizes 'eye" as a
> variable here.  Oh well, Matlab seems to do the same.
> 
> So the only real "bugs" that I see in the current code are:
> 
>   * It doesn't recognize "_" in symbol names.  Matlab R13 does not
>     recognize leading underscores, but does recognize embedded
>     underscores.  Perhaps that is a bug?

ok, this is a bug..

                  if (! isalpha (c) || c == '_')

should read

                  if (! isalpha (c) && c != '_')

I also missed a trailing digit on the last arg, so that inline('a+x1')
wouldn't work either...

>   * It doesn't handle things like
> 
>       inline ('foo (''bar baz'', x, y, z)')
> 
>     correctly -- the only args should be x, y, and z.

Didn't think of that one... Grrrr... Ok, think for that and the aboved
attached.

>   * It doesn't use "x" as the default variable name, passed when no
>     other variables are recognized (why it does this, I have no idea).

Yes I thought about, this but then thought it wasn't worth treating
as if there are no args, whats the point of defining an arbitrary one..

> Finally, fixing these things is not all that important to me.  I'd
> file this in the category of bug-for-bug compatibility.  I think
> the only safe thing to do is always specify the arguments explicitly.  

I promise I'll leave it alone after this.. Its taken way too much time...

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

patch.sort20040924
Description: Text document