On Oct. 7, Raymond Toy wrote:
---------------------------
> Stick the following in, say, j4save.lisp:
-----------------------------------
Thanks for the error msg. surpression code,
which works fine.
......................
(%i1) load("j4save.lisp");
(%o1) j4save.lisp
(%i2) quad_qags((x-2)^2*sin(4000*x),x,2,3);
***MESSAGE FROM ROUTINE DQAGS IN LIBRARY SLATEC.
***INFORMATIVE MESSAGE, PROG CONTINUES, TRACEBACK REQUESTED
* ABNORMAL RETURN
* ERROR NUMBER = 1
*
***END OF MESSAGE
(%o2) [- 1.6023580453445113E-4, 0.0052996692150713, 8379, 1]
(%i3) quad_j4save('control, 0);
(%o3) 2
(%i4) quad_qags((x-2)^2*sin(4000*x),x,2,3);
(%o4) [- 1.6023580453445113E-4, 0.0052996692150713, 8379, 1]
(%i5) quad_j4save('current_error);
(%o5) 1
(%i6) quad_j4save('control);
(%o6) 0
(%i7) printfile("j4save.lisp");
;;; j4save.lisp
;;; raymond toy
;;; Oct., 2011
(in-package :maxima)
(defun quad-j4save (parameter &optional new-value)
(values (slatec::j4save (case parameter
($current_error 1)
($control 2)
($max_message 4))
(or new-value 0)
(if new-value t nil))))
(defun $quad_j4save (parameter &optional new-value)
(quad-j4save parameter new-value))
(%o7) j4save.lisp
...............................................
---------------------------------------------
>What will you do with the rough value? Why not just try both qag and qags
>and choose the one that gives the "better" answer?
>
---------------------------------------------------
I had the same idea - go for a rough value using both qag and qags and
look at the number of function evaluations needed; the one that needs
the smallest # of func evals should then be tried first to get desired
precision.
-------------------------------------------
>You might find the following interesting:
>http://trac.common-lisp.net/f2cl/browser/packages/quadpack/quadpack-tests.lisp
-----------------------------------------------
Thanks for the test code. I can use these ideas to test nint.
-------------------------------------------
>These are a bunch of tests given in the quadpack book. There are a bunch
>of
>tests illustrating the performance of several algorithms on different
>integrals. Some are comparisons of the same integral with different
>algorithms.
>
>The book also said something about having to do some thinking before
>applying the algorithms. I believe there was an example there that was
>very
>difficult for quadpack, but a little bit of thought allowed you to change
>the integral into something that was much easier. There was also some tips
>on how to do multiple integrals that might be useful. (There was a
>restriction there on using different algorithms for the multiple integrals,
>but maxima shouldn't have that problem because all the storage is local, so
>recursive calls should not be a problem.)
-------------------------------------------------
Thanks for the reference. I have ordered a copy of Piessens' Quadpack:...
Ted