On Thu, Sep 18, 2008 at 10:07 AM, Waldek Hebisch wrote:
>
> Bill Page wrote:
> <snip>
>> InputForm values generated by coercions are exactly those that we
>> need to be able to unparse for the Sage interface (and perhaps as
>> input to other systems) so that with a minimum translation they may
>> often be able to reconstruct accurate versions of these values.
>>
>> So far I do not know of any way to generate $ package calls or @
>> result assertions through such coercions.
>>
>
> Currently large part of coercion to InputForm is uniplemented and
> some parts are wrong (like the example you showed). I believe that
> package calls and @ are important tools when fixing this problem.
>
I understand the issue but I am not yet convinced that package calls
and result assertions are necessary or desirable when coercing other
values to InputForm. On the other hand, I have no objection of course
to including these for other reasons.
In the case of coercion to InputForm most domains naturally implement
some simple ways to generate values of this domain. Usually these are
chosen to be convenient for the user or for the interpreter interface
to the library. For example, the 'Float' domain exports the function
'float'
(1) -> float(1,0,2)
(1) 1.0
Type: Float
So it is very natural that we implement coercion from Float to InputForm as
(2) -> unparse(%::InputForm)
(2) "float(1,0,2)"
Type: String
Although we could generate "float(1,0,2)$Float" in this case we do not
need to generate the package call because the signature of
'float$Float' is deliberately chosen to be unambiguous in the
interpreter (parse). I believe this is typical of the design of most
domains.
> Below is improved patch: I have cleaned code a bit and added
> support for "::", "@", "$" (package calls) and "pretend". I keep
> handling of "/" and unary minus like in original patch.
>
I just tried this patch to 'format.boot' from FriCAS rev: 370 using
the examples on the wiki page:
http://axiom-wiki.newsynthesis.org/SandBoxUnparse
This version fails on the following example that we previously discussed:
integrate(sin(x)^2+cos(x+1)^2,x)
unparse(%::InputForm)
It results in the error message:
Break.
Broken at FUNCALL. Type :H for Help.
BOOT>>
>> System error:
The variable READ is unbound.
and the following two tests involving repeated division
parse("a*b/c/d")
unparse(%)
parse("a/b/c/d")
unparse(%)
result in the same message.
All other results on this page are the same as shown on this page
except for few more redundant parenthesis in some cases (due to
different treatment of / ).
> BTW: Yesterday I checked (with earlier version) that most of
> differences in output is due to parentheses around single
> argument to function calls. While this may be treated as
> regression, I think that such parentheses save us a lot of trouble
> so I prefer to always have them.
I agree except perhaps for relative precedence of * and /. But this
redundancy does not cause any problem.
> Other changes seem to be smaller and looked OK.
>
Great. It would be nice to have this new version of 'format.boot' in
the next release of FriCAS.
> diff -ru dist.bb/src/interp/format.boot dist/src/interp/format.boot
> --- dist.bb/src/interp/format.boot 2008-09-17 00:09:51.000000000 +0000
> +++ dist/src/interp/format.boot 2008-09-18 15:13:08.000000000 +0000
> ...
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
-~----------~----~----~----~------~----~------~--~---
