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