On Thu, Mar 26, 2009 at 5:19 AM, Burcin Erocal <[email protected]> wrote: > > On Wed, 25 Mar 2009 19:56:08 -0700 (PDT) > Alex Raichev <[email protected]> wrote: > >> >> I suppose the same issue applies to other common functions, such as >> the sine function. > <snip> >> sage: sin(QQbar(2)) > <boom> > > You're right, these are easier to fix then the __pow__ problem as well. > > One question we should answer before implementing this is, do we try to > make sense of the argument before we make it a pynac symbolic > expression and apply sin on it? > > I guess not, since we regard all these as purely symbolic expressions. > > But then we have the following: > > sage: from sage.symbolic.ring import NSR > sage: t = NSR(Mod(2,7)) > sage: sin(t) > 0.90929742682568171 > > compare to: > > sage: sin(NSR(2)) > sin(2) > > Should we return sin(2) in the first example as well? Should we raise an > error instead?
The only sensible thing to do if you return sin(2), is have it blow up if you ever try to evaluate it, e.g., float(sin(Mod(2,7))) would go boom. Anyway, I think that obviously, if it is possible to code things so "sin(Mod(2,7))" immediately gives an error, that would be the most desirable solution. However, we definitely don't want sin(2) to immediately simplify to 0.90929742682568171 since that would imply a choice of real precision. One possibility would be that sin(foo) would raise an error if the parent of foo doesn't have a canonical coercion map to CC. Thus sin(Mod(2,7)) would raise an error, sin(QQbar(...)) would not raise an error, and sin(element of a number field without an embedding into CC) would raise an error. -- William --~--~---------~--~----~------------~-------~--~----~ 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/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
