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 -~----------~----~----~----~------~----~------~--~---