# [plt-dev] Inexact integers

On Tue, May 25, 2010 at 7:23 AM, Michael Sperber
<sperber at deinprogramm.de> wrote:
>*
*>* There was also the idea that an inexact number may denote an interval -
*>* and that IEEE floating-point is an implementation of that idea. I think
*>* this doesn't make sense:
*
It doesn't make sense at all, and it would be nice if most programmers
understood this.
>* Of course, it's possible to view an IEEE number
*>* as denoting the interval between the IEEE number just before it and the
*>* one after it.
*
Not easily. The problem is that there are a lot of numbers that are on
asymmetric intervals. 1 and 2 come to mind (but not 3). You would like it
to be the case that 1+1 = 2 and 1+2 = 3, but because the intervals aren't
symmetric, you won't find a consistent definition of addition that causes
both of those to be true. (You could define addition as a lookup table
with 2^52 entries, of course, but it wouldn't be the kind of addition that
normal people talk about.)
>* However, the IEEE operations aren't defined in terms of
*>* those intervals: they are defined (simplifying somewhat) as operations
*>* on "exact" numbers followed by rounding.
*
Followed by rounding *if necessary*. And it often isn't necessary.
Many so-called rounding errors come from the translation from base 10
input to base 2, or from base 2 to base 10 on printing. The computation
itself can often proceed without rounding. For example, integer arithmetic
for add, subtract, and multiply are *exact* for floating-point integer values
in the range -2^52 to 2^52. There will be *no* rounding whatsoever.
Floating point isn't `magic' or a `black art', it's just a little trickier than
rationals, and maybe on par with complex numbers.
--
~jrm