Re: Bi variate to mono variate functions

[David Bateman]

John W. Eaton wrote:

>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.
>  
>
Ok, then in that case it is only fsolve that poses a problem. I think if
we fix the issue with anonymous function handles then quad is find as is.

>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.
>  
>
This was more a wish that gfortran might be used to allow recursion in
the fortran code and therefore nested quad functions etc to be allowed.

The problem with the caching was the non-reentrant code, but rather the
fact that the underlying fortran code expected the user functions,
jacobians and constraint functions to be seperate and would generator a
new function call for each, and thus the need for caching for speed
reasons. The cache itself might be made reentrant if we created a stack
to store the values in the cache. However, is there a real need for
nested fsolve functions?

>  * 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.
>  
>
Yes that was a problem, but wasn't the worst to resolve.

>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.
>  
>
You can easily do this now with function handles.

>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?).
>  
>
Yes an anonymous function handle can't define a jacobian. However, you
can use a string or a named function handle.

function [y, jac] = myfun (x), ....; end

f0 = fsolve ('myfun',...);
f1 = fsolve (@myfun,...);

This doesn't allow fixed arguments though. It seems that matlab allows
cell arrays of function handles like I proposed, and so for fixed
arguments the proposed syntax is then

function y = myfun(x,c), y = ...; endfunction
function y = myjac(x,c), y = ...; endfunction
p = 5;
y = fsolve({@(x)myfun(x,p),@(x)myjac(x,p)}, ...);

though this doesn't appear to be documented, the optim/private function
lsqfcnchk help string seems to imply that this is the case. So the
change I propose will be in the direction that matlab is headed enough
if its not documented in fsolve yet.

>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.
>  
>
Ok, I'll propose something..

D.


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary