On 27 October 2015 at 19:55, 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.
Well, sort of ... The first thing to remember is that underneath all of Axiom/FriCAS there is Lisp, or maybe better said: Lisp provides a kind of high level virtual machine or runtime environment, so ultimately at the "bottom" every datum is represented by some Lisp object. But unlike Axiom itself , Lisp objects are dynamically typed - each value comes with it's own type - while in Axiom a value has a type only in so far as it belongs to some domain. There is more that can be said about this but enough for now. The purpose of 'pretend' is to specify an Axiom domain for a given value. This value may be considered by Axiom to belong to some other domain but 'pretend' overrides this - kind of like a "cast" in other languages or it might originate (as in our case) from the Lisp level and so belong to no particular Axiom domain. (You should ask later on about the use of the domain SExpression). In any case the use of 'pretend' is not type-safe. It is possible (even easy) to produce unpredictable results and even Lisp errors if a value is treated as belonging to a domain with an incompatible representation. > 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, At the Lisp level an object has a type, so yes Lisp knows that the third element of the list is an integer (or more specifically, it's type is UNSIGNED-BYTE 64). but Axiom known nothing about that so we are just telling it to treat it as if it belongs to the Integer domain. Whether or not this is a good idea is highly dependent on the nitty gritty details of the representation of Integer in Axom and the implementation of UNSIGNED-BYTE 64 in Lisp (which may vary from one implementation of Lisp, say SBCL, to another, say CLisp or ECL). It works for us in SBCL but I could not guarantee that it will in other Lisps. This is something to study more deeply and test in various situations. > and we can define the final value "neval" to be an integer. But Axiom can't so that is exactly why the programmer needs to use 'pretend'. > > Second, the underscores in "INTEGRATION_-QNG_-LIST". Are these just > to escape the hyphens, lest SPAD confuse them with minus > signs? Ah, an easy question with an easy answer: Yes. > 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? Lisp is case-insensitive by default. Lisp uses a special notation if symbols need to be in both upper and lower case. I think Kurt mentioned this earlier. In Lisp |abc| with vertical bars, represents the symbol 'abc', while abc without vertical bars, represents the symbol 'ABC'. > > 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 am flexible. > > I do find the mixture of SPAD and Lisp with their individual conventions > and behaviours very confusing. > Granted. I did mention the BOOT language earlier, right? :) But in Axiom terms this situation isn't very confusing (yet)! > <Australian Accent>I tells ya, there's nuthin' like Axiom for makin' a > bloke feel stupid!</Australian Accent> > Too bad there isn't a good way to include THAT in an email. 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.
