Hacker News Reader

Comment by kibwen | Hacker News Reader

I like to consider what it would look like if a programming language forbade floating point literals from containing inexact values. This means that a literal like `0.1` would be disallowed, and you would instead be forced to write out the literal as the exact nearest representable value `13421773e-27`. Profoundly awful for usability, but at least nobody could ever claim to be surprised that floating point values are imprecise. :P

View on HN

not quite the same, but Scheme has rationals.

Now that I think about it, the Scheme standard (R5RS at least) does not require an implementation to support the full numeric tower. I can't remember which parts are required, but I do wonder now if it permits an implementation that only has rationals and drops floating point. Most implementations, obviously, go the other route and only support floats. But it would be interesting to see.

I like the idea, but on a second thought, it is easily fooled:

    >>> 3.0/10.0 == 1.0/10.0 + 2.0/10.0
    False

No need to even go up to this point. Numbers that are too different are enough 1e300 + 1 will be equal to 1e300. And it would still be even if 1 was added 1e300 times.

And you could not write 1e300 since it is not exact

You need to write 1000000000000000052504760255204420248704468581108159154915854115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233794788090059368953234970799945081119038967640880074652742780142494579258788820056842838115669472196386865459400540160

Now, I feel dumb for not noticing the "+ 1" was not needed. Completely forgot 1e300 would not map on a factor of 2, thanks for the correction.

Reply on news.ycombinator.com