Hello,
> I think it is not so bad since by defining the function float
> appropriately this can easily parse this into a Sage floating point.
> If this really is inconvenient then the
>
>> The linear representation of the object is much less important
>> than it being human readable.
>>
>
> -1 No! I disagree strongly with this.
There are two different things going on here. When you display an
object, the purpose is to let the human know what the object is. The
unparsed version of float does definitely not do that. Converting
objects between systems is a totally different problem.
> It seems to me that the reason why 2-d output from Maxima and other
> external packages is disabled is specifically to enable them to
> interact.
The 2-d output is disabled is simply because it's just more to get
them to print nicely (for example, if you have a Python list of maxima
objects).
> The Axiom interface was intentionally modeled after the
> Maxima interface and I still believe that it should operate in
> essentially the same manner.
> Your change breaks what I consider to be
> one of the most important features of the Sage:
...
> sage: axiom(maxima('1/2'))
>
> 1
> -
> 2
> sage: maxima(axiom('1/2'))
> -1
The only reason these examples work is by chance. The current code
was not designed to work this way, and this approach would only work
in general for the simplest of examples (such as integers or rational
numbers). Expecting one system to recognize a particular string
representation of an object just isn't feasible. What should be done
is a conversion path Axiom -> Sage -> Maxima and vice versa. It's
only a couple lines of code to add those hooks.
> When producing printed output I suppose that really Sage should do
> things in a more object-oriented manner and simply ask the external
> package to display it's own objects in whatever manner is natural for
> that package. But there needs to be a common "linear representation"
> available when passing computations from one package to another and to
> native Sage.
There have two main approaches taken in converting objects from other
systems into Sage. With Magma, there is some code written in Magma's
language which produces the Sage commands used to create the object.
William will be working a lot this upcoming quarter on making it so
that pretty much any object can go back and forth between Sage and
Magma. For the Macaulay2 code, all of the logic is on the Sage side.
You can look at the to_sage method at
http://www.sagemath.org/hg/sage-main/file/69d774a64568/sage/interfaces/macaulay2.py.
The way an object gets converted into Sage depends on its type in
Macaulay2.
What's more important than what string representations you choose to
use is figuring out how to get answers to questions like "what are the
generators of the polynomial ring?" or "what is the term order of the
polynomial ring?", etc.
--Mike
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
