Orright... two questions about
https://github.com/billpage/gsla/blob/master/gsl.spad, and in particular
the final three lines:
gslIntegrationQng(f,a,b) ==
r:List DF:=INTEGRATION_-QNG_-LIST(mkLispFunction1(f@(DF->DF))$Lisp,a,b)$Lisp
[r(1),r(2),r(3) pretend Integer]
First the use of "pretend". As I understand it, "pretend" is a sort of
syntactic fudge factor to allow Axiom to compile code in which the types
may not be precisely fixed, or in which there may be a type mismatch. But
why is it needed particularly here - in the definition of
gslIntegrationQng? Surely an object is either an integer or it isn't, I
would have thought, and we can define the final value "neval" to be an
integer.
Second, the underscores in "INTEGRATION_-QNG_-LIST". Are these just to
escape the hyphens, lest SPAD confuse them with minus signs? After all, the
relevant function is defined in gsl.lisp as
defun integration-qng-list (f a b)
(multiple-value-list (integration-qng f a b)))
which incidentally would appear to indicate that one of the languages here
is case-insensitive. Or is there another reason?
With regard to plain text format, I fully agree, and I'll do that if people
want. On the other hand, it's nice to have some way of distinguishing code
samples from text - the use of markdown is good for this, but I don't know
if google groups supports it. (Well, it sort of does, but through a
browser extension called "Markdown Here" which also supports LaTeX.)
I do find the mixture of SPAD and Lisp with their individual conventions
and behaviours very confusing.
<Australian Accent>I tells ya, there's nuthin' like Axiom for makin' a
bloke feel stupid!</Australian Accent>
-Alasdair
On Wed, Oct 28, 2015 at 12:54 AM, Bill Page <bill.p...@newsynthesis.org>
wrote:
> 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 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.
>
--
[image: http://www.facebook.com/alasdair.mcandrew]
<http://www.facebook.com/alasdair.mcandrew> [image:
https://plus.google.com/+AlasdairMcAndrew/posts]
<https://plus.google.com/+AlasdairMcAndrew/posts> [image:
https://www.linkedin.com/pub/alasdair-mcandrew/a/178/108]
<https://www.linkedin.com/pub/alasdair-mcandrew/a/178/108> [image:
https://twitter.com/amca01] <https://twitter.com/amca01> [image:
http://numbersandshapes.net] <http://numbersandshapes.net>
--
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.
