No doubt the sage system is a bit too ad hoc. However, this is something that will be fixed in the symbolics rewrite. While externally it will maintain most backwards compatibility, internally it will be vastly different (for example, elements (including variables) in the "symbolic ring" (which is no longer even necessarily a ring!) no longer necessarily commute, etc). Care is being taken to make it significantly less ad hoc. Right now, most functionality of the sage.calculus module is dictated strictly by how maxima is designed. As we move to our own internal reperesentation, this obviously will not be sufficient. I'd be interested in hearing which features of FriCAS/OpenAxiom has that might be useful in more detail. My main technical concerns are that anything interacting through a pexpect interface is going to be slow and will not interact with Sage's internal coercion system (aside from the fact that adding another dependency to the standard core increases code complexity for symbolics dramatically). I downloaded FriCAS to try to investigate, but I couldn't find a good introduction to the high level structure of the FriCAS code (at the file level). Does such a thing exist?
-- Gary Furnish On Wed, Apr 23, 2008 at 9:49 AM, Bill Page <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 4:28 AM, Michael.Abshoff wrote: > > > > Martin Rubey wrote: > > > > > I do not see how the problem of differing representations can be > > > resolved. Up to now I thought that Sage simply doesn't have an > > > "internal" representation, and just uses the one from the external > > > program - that's how my polymake interface for FriCAS/Axiom > > > works. > > > > I am not 100% clear, but I believe for elements in a symbolic ring > > we do not yet have a Sage internal representation. It is being written > > in Cython since arithmetic is probably slowed down by a factor of > > 10,000 by using pexpect+Maxima. That is largely the fault of pexpect. > > > > I think that what Martin means is that if Sage has it's own internal > representation of something then the problem of converting from one > representation to another is unavoidable if the symbolic manipulation > is done by an external program. This is independent of whether one > uses the pexpect interface or not. Of course if symbolic manipulation > is implemented in the Sage interpreter or compiled Cython code, then > this conversion may not be necessary. However it is sometimes > convenient also to change the internal representation depending on the > type of manipulation to be done. > > So far as I can see Sage does have an internal representation for > "Symbolic Ring". > > But the idea of a "Symbolic Ring" seems very strange to me. What is > this from a mathematical point of view? How is it different from, say, > a polynomial? Do you really mean that the variables of the ring do not > commute as in the sense of a free algebra? > > http://en.wikipedia.org/wiki/Free_algebra > > I worry sometimes that the Sage type system is a little too ad hoc... :-( > > Anyway, here is an example computation that includes conversion from > the internal Sage representation to the internal Axiom representation > of a symbolic object: > > [EMAIL PROTECTED]:~# sage > ---------------------------------------------------------------------- > | SAGE Version 3.0, Release Date: 2008-04-22 | > | Type notebook() for the GUI, and license() for information. | > ---------------------------------------------------------------------- > > sage: # Construct some symbolic expression in Sage > sage: var('a b c d') > (a, b, c, d) > > sage: A = matrix([[a,b],[c,d]]) > > sage: A > > [a b] > [c d] > > sage: x=det(A) > > sage: x > a*d - b*c > > sage: x.parent() > Symbolic Ring > > sage: x? > Type: SymbolicArithmetic > Base Class: <class 'sage.calculus.calculus.SymbolicArithmetic'> > String Form: > > a d - b c > Namespace: Interactive > Docstring: > > Represents the result of an arithmetic operation on > f and g. > > sage: # Convert it to an object in Axiom > sage: y=axiom(x) > > sage: y > a*d+(-b*c) > > sage: y.type() > Polynomial Integer > > sage: y? > Type: AxiomElement > Base Class: <class 'sage.interfaces.axiom.AxiomElement'> > String Form: a*d+(-b*c) > Namespace: Interactive > Docstring: > a*d+(-b*c) > > > ... > > So: What should you do: > > > > a) wait a week or two for ecls and gdbm to become optional > > b) build an optional FriCAS/OpenAxiom spkg using ecls > > c) write a pexpect interface to use integration/ODE/guess if that > > is something where you see FriCAS/OpenAxiom as "better > > than anything else". > > > > In parallel take a look at > > > > http://wiki.sagemath.org/spkg/InclusionProcedure > > > > and write some proposal *why* FriCAS/OpenAxiom should become > > part of standard Sage and *what* it should/can [via pexpect] do. > > ... > > Martin I would be interested in working with you on doing this (and > anyone else who would like to join in), that is provided you are > willing to take the lead. :-) > > > Then eventually it will come down to the vote and if for example > > FriCAS beats Maxima and the 4Ms at integration I would consider > > it very like that it could make it in. FriCAS full [without gcl] weighs > > in at 9MB, so if you can strip out unneeded parts for an initial bare > > bone distribution it would be great. > > > > Do you mean, for example eliminating the hyperdoc browser and Axiom > graphics? I think that trying to eliminate mathematical functionality > is not likely to save much in a "bare bones" distribution. > > Regards, > Bill Page. > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
