Alasdair,
There is stuff to read such as Ralf suggests but in my opinion just
hitting your head against something relevant hard enough for long
enough is much more effective :) Kurt's example code is short enough
not to cause much harm, so why not start just by asking one to two
questions rather than making a list? As I am sure you tell your
students, the first step is not letting it make you feel intimidated.
Just ask.
Concerning my question about naming conventions: My preference is to
avoid all redundant prefixes so Maxima isn't such a great model. I am
not sure I understand the intention of your examples
>> v := quad(x+->exp(-x^2),0,1,1.0e-10)
>> qag(v)
but yes, that is more or less what I would like. The term "domain" in
Axiom has a particular meaning: a data/mathematical type or class.
For the purposes of extending Axiom to include more operations on
existing domains, e.g. DoubleFloat, a "package" is more appropriate.
Because GSL is a rather large library, it might be appropriate to
define more than one package but right now we have only one named
'gsl'.
Actually, using a package/domain name like 'gsl' consisting of all
lower case letters is contrary to the general conventions in the
Axiom/FriCAS library. Unlike variable and functions names, these names
are supposed to start with a capital letter. Each package/domain also
has a short (< 6 characters) abbreviation, by convention written in
all upper case. So we should probably at least change the package
name from 'gsl' to 'Gsl'. In keeping with what I said above, maybe we
would want package names such as 'GSLintegrate' etc.
As you see in examples, in many contexts we can avoid explicitly using
the package/domain name since it is automatically deduced by the
interpreter.
Concerning your suggested packages: Note that there is already
extensive support in Axiom/FriCAS for Groebner basis compuations. Did
you have something specific in mind? BLAS and LAPACK might be
interesting. As I understand it there are already interfaces to these
packages in GSL.
One thing I tried last night (unsuccessfully) was to call
'lu-decomposition' the GSLL equivalent of 'gsl_linalg_LU_decomp'. I
have a problem converting the matrix passed by FriCAS to the required
matrix format. This is the kind of thing we need to resolve for using
more general routines.
BTW, There is or once was a policy promoting the use of plain text
email format on mailing lists. I notice yours arrive with a more
modern look. There might be some people around who prefer the older
format.
Bill.
On 27 October 2015 at 08:25, Alasdair McAndrew <amc...@gmail.com> wrote:
>
> Sorry to be an idiot - but where's a good place to go to learn about
> spad/boot/lisp
> insofar as they relate to PanAxiom development? I've been looking over Kurt's
> gsl.lisp and gsl.spad and there are quite a few things which confuse me. I
> won't
> list them, as it would be a depressingly long list for two very short files...
>
> On Tue, Oct 27, 2015 at 2:20 PM, Alasdair McAndrew <amc...@gmail.com> wrote:
>>
>> We can just go the Maxima approach, and write quadQag, quadQng etc (Maxima
>> has quad_qag, quad_qng) - this retains the naming convention from QUADPACK.
>> Or we could have a domain QUAD which included operations qag, qng etc...
>> like this:
>>
>> v := quad(x+->exp(-x^2),0,1,1.0e-10)
>> qag(v)
>>
>> As to other quicklisp libraries, BLAS, LAPACK? What about CL-BUCHBERGER - a
>> common lisp implementation of Buchberger's algorithm for Groebner base
>> computation? The place to search is quickdocs.org.
>>
>> Note that QUADPACK is far from being the last word of numeric quadrature
>> routines: I have been experimenting with the integral of sin(1/x) between
>> x=0 and x=1, and pretty much every routine quits in disgust with an error.
>> That's why I would also like to implement a scheme for tanh-sinh integration.
>>
>>
>>
>> On Tue, Oct 27, 2015 at 1:37 PM, Bill Page <bill.p...@newsynthesis.org>
>> wrote:
>>>
>>> Here is a little design issue concerning names.
>>>
>>> Right now we have the example of 'gslIntegrationQng' and I have
>>> started to fill in some miscellaneous functions such as
>>>
>>> gslLookup: String -> Symbol
>>> ++ \spad{\gslLookup} finds GSLL function by GSL name and
>>> ++ displays some documentation.
>>> gslIsNaN?: DF -> Boolean
>>> ++ \spad{\gslIsNaN?} returns true if x is not-a-number.
>>> gslIsInf: DF -> SingleInteger
>>> ++ \spad{\gslIsInf} returns +1 if x is positive infinity,
>>> ++ -1 if x is negative infinity and 0 otherwise. On
>>> ++ some platforms 1 is returned for negative infinity.
>>> gslFinite?: DF -> Boolean
>>> ++ \spad{\gslFinite?} returns true if x is a real number,
>>> ++ and false if it is infinite or not-a-number.
>>> gslFcmp: (DF,DF,DF) -> SingleInteger
>>> ++ \spad{\gslFcmp} determines whether x and y are approximately
>>> ++ equal to a relative accuracy epsilon.
>>> gslIntegrationQng : (DF -> DF,DF,DF) -> Record(result:DF,
>>> abserr:DF, neval:Integer)
>>> ++ \spad{\gslIntegrationQng} applies the Gauss-Kronrod 10-point,
>>> ++ 21-point, 43-point and 87-point integration rules in succession
>>>
>>> but before going further it occurs to me to wonder if we really should
>>> continue to use the prefix 'gsl' in all these function names? In
>>> Axiom/FriCAS it is common to overload names and rely on package names
>>> and types for disambiguation. It seems unnecessarily redundant to
>>> write:
>>>
>>> gslIntegrationQng$gsl
>>>
>>> Also, the names that appear at the GSLL (lisp) level omit the gsl
>>> prefix for a similar reason - Common Lisp packaging.
>>>
>>> So I propose that we drop the 'gsl' part of the name and lowercase the
>>> first letter, as is the Axiom custom.
>>>
>>> lookup: String -> Symbol
>>> ++ \spad{\lookup} finds GSLL function by GSL name and
>>> ++ displays some documentation.
>>> isNaN?: DF -> Boolean
>>> ++ \spad{\isNaN?} returns true if x is not-a-number.
>>> isInf: DF -> SingleInteger
>>> ++ \spad{\isInf} returns +1 if x is positive infinity,
>>> ++ -1 if x is negative infinity and 0 otherwise. On
>>> ++ some platforms 1 is returned for negative infinity.
>>> finite?: DF -> Boolean
>>> ++ \spad{\finite?} returns true if x is a real number,
>>> ++ and false if it is infinite or not-a-number.
>>> fcmp: (DF,DF,DF) -> SingleInteger
>>> ++ \spad{\fcmp} determines whether x and y are approximately
>>> ++ equal to a relative accuracy epsilon.
>>> integrationQng : (DF -> DF,DF,DF) -> Record(result:DF, abserr:DF,
>>> neval:Integer)
>>> ++ \spad{\integrationQng} applies the Gauss-Kronrod 10-point,
>>> ++ 21-point, 43-point and 87-point integration rules in succession
>>>
>>> What do you think?
>>>
>>> On 26 October 2015 at 20:44, Alasdair McAndrew <amc...@gmail.com> wrote:
>>> >
>>> > Now that Karl has provided a fantastic working template for an integration
>>> > routine from QUADPACK/GSL/GSLL it should be possible to extend those
>>> > files to incorporate some of the other routines. For the next few days
>>> > I'll
>>> > not have much time, but I'll aim to fiddle later in the week. And I might
>>> > even learn a little Lisp in the process!
>>> >
>>>
>>> My plan is to chip away at adding new routines as time permits. If
>>> there is something in particular you would like to tackle, just let me
>>> know.
>>>
>>> Besides GSL are there some other libraries that might be interesting
>>> and amenable to the QuickLisp approach?
>>>
>>> >
>>> >>
>>> >> Am 26.10.2015 um 17:34 schrieb Bill Page:
>>> >> > I just dropped this "proof-of-concept" level code into a repository at:
>>> >> >
>>> >> > https://github.com/billpage/gsla
>>> >> >
>>> >> > Title: GNU Scientific Library for Axiom (and FriCAS and OpenAxiom)
>>> >> >
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "FriCAS - computer algebra system" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/fricas-devel/q18Av7P3jnM/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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.
>>
>>
>>
>>
>> --
>>
>
>
>
> --
>
> --
> 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.
--
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.
