On 3 November 2015 at 20:03, Alasdair McAndrew <[email protected]> wrote:
>
> A few thoughts:
>
> How do we allow for optional parameters (epsabs, epsrel, limit etc)? The
> approach taken by GSLL, and therefore by me in my version of gsl.spad was to
> overload the integration function, and to give values for the extra
> parameters when they weren't given by the user. This all had to be done in
> order: epsabs, epsrel, limit. This means that you can't set the limit
> without setting epsabs and epsrel first. Is there a "named" way of entering
> optional parameters in spad:
> integrationQng(x+->sin(x^2),0.0,%pi/2,'limit=2000) say? This means that the
> user can set any optional parameters, in any order.
The primary example of something like this is the options for the
'draw' command. You can see the source code in
fricas/src/algebra/drawopt.spad and how it is used in draw.spad. But
a simplified form of this is just
(1) -> vars:=OrderedVariableList [epsabs,epsrel,limit]
(1) OrderedVariableList([epsabs,epsrel,limit])
Type: Type
(2) -> opts:List Record(key:vars,val:Any)
Type: Void
(3) -> opts:=[[epsabs,1.0E-20],[limit,1000]]
(3) [[key= epsabs,val= 0.1 E -19],[key= limit,val= 1000]]
Type: List(Record(key: OrderedVariableList([epsabs,epsrel,limit]),val: Any))
(4) -> opts:=[[notakey,3]]
Cannot convert the value from type Variable(notakey) to
OrderedVariableList([epsabs,epsrel,limit]) .
Using this the syntax for options could be
integrationQng(x+->sin(x^2),0.0,%pi/2,[[limit,2000]])
The outter [ ] forms a list and the inner [option,value] forms a
record. Each function would have to be defined twice - once with
options and once without (to avoid having to write [[]] in each
function). To process the options one must scan the list for specific
keys.
(5) -> for opt in opts repeat output [lookup opt.key,opt.val]
[1,0.1 E -19]
[3,1000]
Type: Void
For more control and a slightly better syntax one can replace this
with a specific domain using this representation similar to DrawOpts.
Of course underneath at the Lisp/GSLL level you would have to pass all
the "optional" parameters and provide your own defaults.
> Improper integrals: GSLL has three separate functions: qagi (integrating from
> -inf to +inf), qagiu (integrating from a to inf, a being finite), and qagil
> (integrating from -inf to b). For each function it makes a substitution so
> that the integral is defined between 0 and 1 - you can see the substitutions
> in the gsl source file integration/qags.c. Thus the GSLL tests for qagi,
> qagiu, and qagil independently. The approach taken in Maxima is to have just
> one function, which they call quad_qagi, which can be used for any integral
> involving infinity, and which makes the appropriate substitution depending on
> which of the limits is finite.
I think maybe Ralf's proposal is a reasonable one. E.g.
(6) -> a:OrderedCompletion DoubleFloat
Type: Void
(7) -> a:=plusInfinity()
(7) + infinity
Type: OrderedCompletion(DoubleFloat)
(8) -> b:OrderedCompletion DoubleFloat
Type: Void
(9) -> b:=3.141592
(9) 3.141592
Type: OrderedCompletion(DoubleFloat)
(10) -> retract(b)@DoubleFloat
(10) 3.141592
Type: DoubleFloat
(11) -> b:=%pi/2
(11) 1.5707963267948966
Type: OrderedCompletion(DoubleFloat)
So then
integrationQng(f,0. 0::DF, plusInfinity())
> Names of functions: gslIntegrationQng, integrationQng, quadQng...? (I like
> the last because it's short!)
Actually as we implement more and more integrations functions it seems
reasonable to me that there be a package specifically for integration,
e.g. GSLintegration. Then the names could appear as qng$GSLintegration
or just 'qng' in the appropriate context.
I would also like to get rid of the requirement to pass a function and
allow just an Expression, e.g.
qng(sin(x^2), 0.0,%pi/2,[[limit,2000]])$GSLintegration
> Other GSL/GSLL functions... I suppose some numerical linear algebra
> (including eigensystems) would be nice, random number generation, and
> numerical ODE solving - GSL supports a host of different methods, mainly
> embedded Runge-Kutta methods of different orders. I think that FFTs and other
> transforms (wavelets) are better suited for purely numerical software, like
> GNU Octave. Also, the GSL implementation of FFT is not the most optimized:
> if we wanted one we should go for FFTW ("Fastest Fourier Transform in the
> West").
>
I have an application where I would like to use a good ODE solver. I
will work on that.
I was also looking into other interesting packages available in
QuickLisp and which might be amenable to the same interface approach
as GSLL. One thing that stood out was graphics such as 'vgplot' as an
interface to GnuPlot
https://github.com/volkers/vgplot
and also Cl-ppplot which is an interface to the even more capable
http://plplot.sourceforge.net/
Cheers,
Bill.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
