Hi Karl-Dieter, On Wed, 30 Sep 2009 07:01:03 -0700 (PDT) kcrisman <kcris...@gmail.com> wrote:
> On Sep 29, 2:30 pm, Robert Bradshaw <rober...@math.washington.edu> > wrote: > > On Sep 29, 2009, at 9:16 AM, kcrisman wrote: > > > > > Dear sage-devel, > > > > > The recently merged Pynac 0.1.9 now automatically evaluates > > > "inexact" (whatever that means) input to most functions, like > > > trig, gamma, etc. > > > > > Should it do this for rationals? > > > > No, I don't think so. > > And in fact this doesn't happen for some, e.g. <snip examples> As you point out, pynac-0.1.9 doesn't evaluate exact arguments to most functions. (The only one I know that is evaluated is factorial().) The fact that some inputs are evaluated is the result of confusion caused by having a __call__, _eval_, and an _evalf_ method for these functions in Sage. I guess Mike had to do things this way, because I misinterpreting the request in #1158 and disabled evaluation in ginac, so he had to work around that when switching over to pynac. I've rewritten most of the symbolic function stuff over the last week. One of the changes was to make the role of __call__, _eval_ and _evalf_ clear. I actually got rid of the __call__. :) I'll try make my changes public although they are no where near complete. Maybe this way interested people can comment and fix the remaining problems, since I don't think I'll have much time for pynac in the next weeks. > > > But > > > in this case it's not obvious how to obtain extra precision > > > except by passing in a RealField(100) element or something, as > > > opposed to sqrt (though sqrt seems to be unique in this regard). > > > > > My thought is that rationals are "exact" enough that maybe they > > > shouldn't be autoevaluated, but I don't know what the consensus > > > would be on that. Thoughts? Or maybe we should just add a > > > 'prec' keyword to all known symbolic functions. > > > > That might be a good idea. > > That's something I could possibly work on. It would be useful as an > alternative to making the user cast everything into RR(n). I suggest you wait to see my patches to the symbolic functions. I don't think you can add a precision parameter without touching pynac (C++) code. Though I'd be happy to make this change myself if we decide to go that way. Adding this parameter to functions, so they evaluate their inexact input with higher precision is just a different syntax for this: sage: t = 0.5 sage: t.prec() 53 sage: gamma(t.n(100)) 1.7724538509055160272981674833 I would like to keep a single syntax if possible. This will also eliminate a lot code dealing with precisions in symbolic functions. > > Another option (perhaps in addition) would > > be to have a context. E.g. > > > > with prec(100): > > [do some stuff] > > I like this option, but this should apply to all preparsed float values in that context. I.e., 0.5 should have precision 100 in this context, not 53. Cheers, Burcin --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
