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.