octave-maintainers
[Top][All Lists]
Advanced

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

Re: Bi variate to mono variate functions


From: John W. Eaton
Subject: Re: Bi variate to mono variate functions
Date: Thu, 30 Mar 2006 16:25:38 -0500

On 30-Mar-2006, David Bateman wrote:

| However, for fsolve, dasrt, daspk,
| dassl and lsode this is a real pain as we've been into a number of
| times. The problem is the jacobian and constraint functions of these and
| how to pass them. Matlab uses optimset('Jacobian') to start that the
| same user function returns a jacobian for example. Thinking about this
| maybe we could easily allow something like the following to work
| 
| function y = myfun(x), y = ...; endfunction
| function y = myjac(x), y = ...; endfunction
| y = fsolve({@(x)myfun(x),@(x)myjac(x)}, ...);
| 
| where we force the user to pass seperate functions for the function and
| the jacobian. Its not completely compatiable with matlab, but it'll be a
| hell of a lot better especially if the user doesn't define the jacobian
| or constraint functions for dasrt, etc and we can easily pass fixed
| arguments like
| 
| function y = myfun(x,a), y = ...; endfunction
| function y = myjac(x,a), y = ...; endfunction
| y = fsolve({@(x)myfun(x,5),@(x)myjac(x,5)}, ...);
| 
| if you think the above is a reasonable compromise to the current issue,
| I'm willing to take a shoot at coding it.

OK, I found an old message from you about this topic.

Let's not worry about compatibility for lsode, dassl, etc., since
those functions are not present in Matlab anyway.

For quad and fsolve, I think it would be good to aim for
compatibility.

I think the problems you pointed out in the past were

  * Caching the values from a function call that returns both F and J
    makes the function non-reentrant.  But that is already the case
    with an f77 compiler, and the static function pointers that we are
    now using, so I don't see this as a big problem.

  * In some cases, the function evaluation and the Jacobian evaluation
    have different argument lists, but I don't think this is a problem
    for fsolve.

Now we also have a problem with passing parameters.  As I recall,
fsolve used to allow parameters to be passed by placing them at the
end of the fsolve argument list, but apparently that no longer works.
So the solution is to use an anonymous function, but then you can't
use an anonymous function to pass parameters and use a Jacobian at the
same time because you can't have multiple outputs with anonymous
functions (what were they thinking?).

Given all of this, I think it is reasonable to also allow the method
you propose above for passing multiple function handles.  Let's start
with that and deal with compatibility later.  I think this change
should be relatively straightforward since we already allow multiple
function names to be passed in a character array.

Thanks,

jwe



reply via email to

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