On Dec 30, 2008, at 1:55 PM, ggrafendorfer wrote: > Hi, > I'm not sure, but I guess this is considered as a bug, please let me > know and I report it to trac: > > sage: a = RealField(100)(5) + float(5); type(a); a.prec() > <type 'sage.rings.real_mpfr.RealNumber'> > 100 > sage: a = float(5) + RealField(100)(5); type(a); a.prec() > <type 'sage.rings.real_mpfr.RealNumber'> > 100 > > the same happens with multiplication, > > actually there are 2 issues: > 1.) the result should have the same precision as the operand with > lower precision,
Yes. > 2.) the result should have the same type as the first operator (we > discussed this once in a different thread were I've been told that > this is a general rule, at least this rule applies between real's with > 53-bit precision and RDF's) This is only the case if there is a coercion both directions, in which case symmetry is broken by taking the parent on the left. > this happens for example with the function 'numerical_integral' which > returns a float, if the result is multiplied with a higher precision > real number the result also magically turns into higher precision. Currently, coercion only goes to Sage parents, as the native types such as float have a very limited "coercion" support (for instance, there is no distinction between the idea of coercion and conversion, and the following works sage: int(float(1/2)) 0 which would be bad to do implicitly). The result should probably be RDF or RealField(53). - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
