Re: Quadpack checked in



Wolfgang Jenkner wrote:
> Raymond Toy <rtoy@earthlink.net> writes:
[snip]

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (defun maxima-numerical-integration (form)
>   (let ((integrator (get (car (pop form)) 'numerical-integrator)))
>     (if (cdddr form)
>         (apply #'call-numerical-integrator integrator
>                (meval `((lambda) ((mlist) ,(cadr form)) ,(car form)))
>                (mapcar #'meval (cddr form)))
>         (apply #'call-numerical-integrator integrator (mapcar #'meval form)))))
> 
> (defun call-numerical-integrator (integrator fun a b)
>   (bind-tramp1$
>    fun fun
>    (funcall integrator fun (mto-float a) (mto-float b))))
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> and the definition for the user-level function would be just
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (setf (get '$qags 'mfexpr*) #'maxima-numerical-integration) 
> (setf (get '$qags 'numerical-integrator) 'mqags)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> 
[snip]

I think this is really quite nice.  Would this allow additional args to 
the integrator?  I'd really like an interface somewhat like plot2d so 
the user can specify additional parameters, like relative error, 
absolute error, array limits, etc.  Using globals for the defaults is 
good, but allowing the user to override it in a call, is quite nice.

> 
> 
>>We should also do something other than force the user to look at the
>>error code to figure out if the integration was ok.  Conditions
>>would be ideal, but it seems gcl doesn't have conditions and/or
>>handler-case/bind, etc.
> 
> 
> The low-level integrator could signal conditions and
> CALL-NUMERICAL-INTEGRATOR could handle them.
> 

Should we not let the user handle them?  If call-numerical-integrator 
handles them, then the user can't do anything about it.

I also got a mail from Vadim V. Zhytnikov that says ANSI GCL, which is 
now required to build maxima, has conditions, so this would be quite nice.

Actually we could now use conditions in a lot more places instead of the 
simple single global catch tag we do now.  The adaptive plot routine 
could benefit from some more precision on what's happening.  Right now, 
it assumes that anything that's not a number is some kind of singularity 
in the function.  This is usually ok, but once in a while, it really 
means the function failed in some way.  But adaptive-plot just keeps 
going, dividing the interval into smaller and smaller pieces.

Ray