A further change could be to integrate for an Expression using a
SegmentBinding:
)co gsl
EF ==> Expression Float
DF ==> DoubleFloat
integrationQng(expr : EF, sb : SegmentBinding(EF)) :
Record(result: DF, abserr: DF, neval: Integer) ==
(var, a, b) := (variable sb, lo segment sb, hi segment sb)
integrationQng(makeFloatFunction(expr,var)$MakeFloatCompiledFunction(EF),a::DF,b::DF)$Gsl
integrationQng(exp(-y^2),y=0..1)
This is arguably more idiomatic.
--- Mark
On 11/04/2015 01:58 PM, Bill Page wrote:
> On 3 November 2015 at 20:03, Alasdair McAndrew <amc...@gmail.com> 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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
