On Sat, Sep 6, 2008 at 12:40 AM, Mike Hansen wrote:
>
> 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.
Yes.
> When you display an object, the purpose is to let the human know
> what the object is.
Yes.
> The unparsed version of float does definitely not do that.
That is just an artifact of the peculiar way that 'unparse' works in Axiom now.
> Converting objects between systems is a totally different problem.
>
As I said, to me this the *most* important issue. If I just wanted the
output printed I probably would not use Sage at all.
>
>> 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).
>
And in the case of a Python list of Axiom objects? How does that work
with Axiom's 2-d output?
But you also said in an earlier thread that using conversions from the
unparsed form was actually the default that is used in the case that
no other specific conversion have been implemented.
>> 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).
That is not true. Exactly this sort of example was used to illustrate
the original design of Sage.
> Expecting one system to recognize a particular string
> representation of an object just isn't feasible.
Of course it has limitations but it works reasonably between pari,
maxima, gap, maple andmathematica now and I can see no reason to
deliberately break this in Axiom.
> 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.
Yes that is the correct way. What is required to replace the old
unparsed output is to implement Axiom -> Sage analogous to the Maxima
-> Sage. The same should be done with the other interfaces such as
maple and mathematica.
>
>> 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.
This could also be done with Axiom, or even more directly by calling
Sage external functions from within Axiom.
> 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.
>
Do you think the way it was done in maxima.py was not correct?
> 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.
>
String representations which specify (or assume) generators and term
ordering are available in all systems by design and so I see no good
reason not to use them until a better approach is implemented.
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
-~----------~----~----~----~------~----~------~--~---
