On Sun, Sep 7, 2008 at 6:12 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> This is unfortunate:
>
> sage: R256=RealField(256)
> sage: R256('1.2')
> 1.200000000000000000000000000000000000000000000000000000000000000000000000000
> sage: R256(1.2)
> 1.199999999999999955591079014993738383054733276367187500000000000000000000000
>
> It's easy to see why this happens: the last input line preparses to
> "R256(RealNumber('1.2'))", so the literal 1.2 gets first made into a
> real number with default (53-bit) precision:
> sage: RealNumber('1.2')
> 1.20000000000000
> and that is then pushed into R256. Since 1.2 does not have a finite
> binary expansion (it has 0011 recurring after the point) this makes a
> difference: R256('1.2') is as accurate as possible (64 repeating
> blocks of 0011 in the mantissa, or something close to that) while
> R256(1.2) gets the first 53 bits right and then fills with 0s.
>
> I'm not saying this is a bug; though if there was a way to get the
> preparser to do the sensible thing with R256(1.2) that would be great.
> But users need to be aware. (The same thing used to happen to me a
> lot with C++ programming).
>
Robert Bradshaw had some thoughts about this before, and will probably
respond tomorrow. Basically there is a solution, but unfortunately I suspect
it would dramatically slow down certain use cases.
-- William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
