On Tue, May 25, 2010 at 7:23 AM, Michael Sperber <sper...@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 _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
