Re: inline functions in Matlab R14

[John W. Eaton]

On 23-Sep-2004, David Bateman <address@hidden> wrote:

| Even worse, what do
| 
| inline('sin (x)')
| 
| and
| 
| inline('y (x)')
| 
| give.. I suspect they give
| 
| ans =
| 
|      Inline function:
|      f(x) = sin (x)
| 
| and
| 
| ans =
| 
|      Inline function:
|      f(x) = y (x)
| 
| 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?

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

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

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

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?

  * It doesn't handle things like

      inline ('foo (''bar baz'', x, y, z)')

    correctly -- the only args should be x, y, and z.

  * 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).

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.  

jwe