I may have the wrong end of the stick here but the last NAG version of AXIOM offered conversion to OpenMath format for AXIOM types. Isn't that what is needed here?
Regards Themos Tsikas On Sep 6, 8:42 pm, "Bill Page" <[EMAIL PROTECTED]> wrote: > On Fri, Sep 5, 2008 at 11:58 PM, Waldek Hebisch wrote: > > > Bill Page wrote: > > >> Ooops, I forget to complete this thought in my last message: > > >> On Fri, Sep 5, 2008 at 10:14 PM, Bill Page wrote: > >> ... > >> I think the best way to solve this problem is to adapt "unparse" to > >> produce a more commonly employed linear format. This is a > >> correction that can be considered upstream by the FriCAS > >> developers. But in the mean time the Sage interface can apply > >> a temporary fix. > > > I wonder why you want unpase: unparse produces infix form. If > > you want to build Sage expression you need to parse it. Fully > > parenthesised form like S-expression is much easier to parse. > > What is desired is something that can be passed to other packages (and > sage) in a format that is very similar and overlaps to a large extent > the input language accepted by those systems. Very few (if any) accept > S-expressions as an input language. The parsing is to be done by the > external package so it is presumed that the difficulty of parsing is > already handled by that package. > > > Have you looked at: > > > PRETTYPRINT((matrix [[1, 2], [3, 4]])::INFORM)$Lisp > > (+ (** |x| 2) 15) > > (1) () > Type: SExpression > > > PRETTYPRINT((integrate(exp(sqrt(x^3-1)), x))::INFORM)$Lisp > > (|integral| (|exp| (** (+ (** |x| 3) -1) (/ 1 2))) (|::| |x| |Symbol|)) > > (2) () > Type: SExpression > > > If you or Sage folks do not like Lisp form it is rather easy > > to produce something like: > > > +(^(x,2),15) > > > or > > > (((x)^(2))+15) > > The latter (infix) form is normally what would be acceptable to an > external package (e.g. Maxima, Maple, etc.) That is the primary reason > for calling unparse. If there were some other way to produce the infix > form that would be fine too. > > > BTW: for unparse it is bad idea to transmit float as strings. > > Namely, parsing result of unparse is supposed to give "equivalent" > > expression. > > Could you define what you mean by "equivalent". To me 'unparse' > implies that it should generate a form that when input to the > interpreter as a string would produce the same expression. I agree > that the current implementation of 'unparse' fails that test in many > cases. > > > But printing a float and reading it back is likely to mangle the value. > > Printing is not important but representing an object as a string is > important. Currently both > > float(156649750673941512323,-66,2) > > and > > 2.123 > > produce the same result when input to the interpreter: > > (1) -> test(float(156649750673941512323,-66,2)=2.123) > > (1) true > Type: Boolean > > Can you give an example when this might not be the case? > > Regards, > Bill Page. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~----------~----~----~----~------~----~------~--~---
