Thank you Yrogirg for the question and thank you Ralf for the answer. I agree that this is both a very relevant and fairly deep question about Axiom. Understanding the Expression domain is very important for a real understand of how Axiom works and helps a lot to understand why it is so different than most other CAS. I recall a few papers and notes the early days of Axiom about the design of Expression. I will try to find them in my archive when I get back home.
I especially like Ralf's 2nd answer "false" - If you intend to try to use Axiom like you would use any of the other computer algebra systems then there really is no way to avoid Expression. In a sense it is one the deepest (highest?) domains in the Axiom type hierachy, i.e. a result of a rather large number of nested dependent definitions that correspond (more or less) to the way mathematics itself is presented from it's foundations. On the other hand there is a tree-like domain in Axiom simply called InputForm which does the job of just symbolically representing an expression. In Axiom this domain is in fact used very little. It is just an intermediate parsed but otherwise unevaluated form of an expression. It has no other associated type information. One of the core processes in Axiom is the semantic evaluation of the types that are to be associated with the various parts of the InputForm and ultimately the InputForm is completely replaced with a new type corresponding to it's final value. This process usually does not involve any of the "rewriting" operations that one might find in Mathematica for example. If you really wanted this sort of thing, in my opinion an extension of InputForm would be a good choice for implementing it. But this would be very much against the design philosophy of Axiom. (There is also the Pattern domain which makes it possible to do such rewriting at a higher level in Axiom.) Regards, Bill Page. On Thu, Mar 17, 2011 at 5:56 AM, Ralf Hemmecke <[email protected]> wrote: > On 03/17/2011 10:19 AM, Yrogirg wrote: >> I failed to find the answer in axiom books (at least in first few). It >> is only said that "The type Expression Integer (abbreviated EXPR INT) >> is used to represent general symbolic expressions in Axiom". >> >> What is the underlying theory (I guess the one that underlies all >> CAS's)? Is there a technique to avoid this general type? Or why it >> should not be avoided? > > Wow! What a question. Browsing through the history of the mailing archive, > you'll find that I also don't like "Expression" very much. > > The answer for whether "EXPR INT" represents a general expression is true > and false in some sense. > > True, because it is the way to take general input of a user (which is > usually an expression -- actually even only a string of characters) and > transforming that into some typed FriCAS object. Since there some guessing > is involved and it doesn't succeed all the time, there must be some > fallback. EXPR INT is such a fallback. It is somehow a necessary evil for > the interpreter. When it however comes to library programming, I am very > much for avoiding EXPR altogether. > > The answer is false, because, the implementation of EXPR INT is not what > perhaps other CAS do or how one would imagine an ordinary expression tree. > FriCAS tries to figure out what the smallest units of the expressions are. > Such "smallest units" are known by the term "kernel" (see Kernel as the > corresponding domain). And then FriCAS tries to represent the expresssion as > a rational function with coefficients being from INT (the argument of EXPR) > and "variables" being these kernels. > > If you look more carefully through the implementation of EXPR, then you find > that there is not even just one internal representation. > >>grep '^ *Rep' expr.spad.pamphlet > Rep := Fraction MP > Rep := MP > Rep := FreeAbelianGroup K > Rep := K > Rep := RF > > I hope that helps a bit. > > Ralf > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/fricas-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
