[Python-ideas] Yet another sum function (fractions.sum)

[Henshaw, Andy]

From: Python-ideas [mailto:python-ideas-bounces+andy.henshaw=gtri.gatech.edu at python.org] On Behalf Of Chris Angelico
Sent: Thursday, August 22, 2013 7:11 AM

> >>> (1<<64)*3//2+10
> 27670116110564327434
> >>> (1<<64)*3/2+10
> 2.7670116110564327e+19
> 
> It's not so large that it cannot be converted to floating point, but it's above
> the point at which floats are accurate to the integer.
> Therefore precision has been lost. Is it obvious from the second line of code 
> that this will be the case? Obviously if you "mix in" a float, then it'll infect the 
> calculations. But the effect of the / operator is less obvious. Fortunately it's
> consistent. It will ALWAYS return a float. However, I do see this as "implicit" conversion.
>
>Anyway, this is somewhat off-topic for this thread.

One of the things that I always admired about the Occam programming language was that you had to explicitly state whether to ROUND or TRUNC when converting from integers to floats, for exactly this reason.  A 32-bit integer potentially has more precision than a 32-bit float, so you had to tell the compiler how to handle the dropped bits.