A quickie: ")read /home/amca/quicklisp/setup.lisp" works in FriCAS, but not in efricas. Why not? Also, the history mechanism in FriCAS in a console seems a bit odd: sometimes (well, often), a previous command, obtained using the arrow keys, will have extra characters, or chanrecters missing (I'm using Konsole: the KDE console, with my term=xterm.)
On Wed, Oct 28, 2015 at 10:55 AM, Alasdair McAndrew <amc...@gmail.com> wrote: > 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> > -- [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.
