From maintainers-request at octave dot org Fri Mar 31 02:56:26 2006 Subject: Re: Bi variate to mono variate functions From: David Bateman To: "John W. Eaton" Cc: maintainers at octave dot org Date: Fri, 31 Mar 2006 10:52:06 +0200 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({ at (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({ at (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 ( at myfun, dot dot dot ); 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({ at (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 David dot Bateman at motorola dot com 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