On Fri, 07 Jul 2017 17:37:46 -0700, bdug...@matatu.org wrote:
> I realized this occurs since 1e100 is a Num rather than an Int (and
> summing to e.g. 10¹⁰⁰ works fine). It could be argued that this is
> not a bug since Nums are not arbitrary precision.
Yeah, I missed you in the IRC channel with the answer on what's going on:
<Zoffix> yeah it's a bug in Range.int-bounds. It's supposed hang. 1e100 is
a Num and there you have only 15 digits of precision,
so the other 86 digits are all floating point noise. The buggy
Range.int-bounds erroneously converts that 15 digits + 86 digits
of noise into a Int, which is why you get the wrong sum. And the
reason the fixed version hangs is because when failing to
find .int-bounds, it'll fully reify the range to get the elements,
but while doing that you're again hit with limited precision
in the 1e100 and once the reification reaches 1e15, the next +1 to
it would still end up a 1e15 (not enough precision for +1),
so it'd loop at that point forever. We can probably improve that
to give an error tho
I opened RT#131718 for it too, but now that I slept on it (even though I
haven't been to bed), I'm going to reject both tickets as not a bug. It's just
a natural outcome of treating limited-precision numbers as 100% precise and
getting the prize of floating point noise in return.
The fun of floating point numbers is ubiquitous in programming and trying to
baby-sit users and checking all the values are precise enough
and can be .succ'ed would probably do more performance damage and surprise
throwage on large numbers than any good by detecting potential mis-use
of a Num (instead of a Rat or Int).
