Bill Page wrote: > > 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. >
What you wrote works for "simple" domains. But many domains have parameters. For example, given: (x^3+1)::Polynomial PF(5) you need some way to get the prime 5 into InputForm. > > 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. > Again test for infinite recursion fired when it should not. You may remove line with BREAK from appOrParen, or better change begining of binop2String and appOrParen to be as below (only the 2 lines which contained '$curOp' has changed). binop2String x == $curExpr : local := x x is ["=", arg1, arg2] or x is ['"=", arg1, arg2] => concat(sumOrParen(arg1), '"=", sumOrParen(arg2)) ... appOrParen(x) == SYMBOLP(x) => formWrapId x INTEGERP(x) => WRITE_-TO_-STRING x ATOM(x) => concat('"(", form2String1(x), '")") [op, :argl] := x (op = "-" or op = '"-") and #argl = 1 => concat('"(", '"-", appOrParen(first argl), '")") EQ(x, $curExpr) => BREAK() op is ["$elt", f, t] => -- Waldek Hebisch [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
