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

Reply via email to