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

[Chris Angelico]

On Thu, Aug 22, 2013 at 8:58 PM, Oscar Benjamin
<oscar.j.benjamin at gmail.com> wrote:
> If the int is out of range you'll get an error:
>>>> 1.0 * (10 ** 1000)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> OverflowError: long int too large to convert to float
>
> An implicit float conversion does not quietly lose precision. All
> subsequent values are usually infected and get turned into floats. The
> implicit float conversion only happens in two cases:
> 1) You mixed a float into your otherwise exact integer computation.
> 2) Division.

>>> (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.

ChrisA