My 2 cents, The word 'real' means quite another thing in mathematics than in a programming language. That may be unlucky, but as a programmer you soon find out the distinction. Whatever presentation you select, all machine presentable numbers are exact, in principle. We adorn a number with the predicate 'inexact' if it was fed into the program as inexact (for example a datum retrieved from inexact measurements) or if it is the result of a function (such as log) that can at best produce an (internally exact) value close the exact value. In PLT Scheme, now Racket, all reals are rationals. This is a reasonable choice, I think. But let's not forget that it is possible to represent sets of numbers that in meaning (not in cardinality, for each representation is necessarily countably finite and in practice even finite) may be approximations of irrational numbers. It is possible to represents sets of numbers that include non rational reals (in mathematical sense), for example by representing a number by a sign followed by a finite list of exponents of the prime factors of the square of the number (as can be useful in group theory) Also notice that number like pi gamma and e can be represented exactly (just by their names) In general computations with these numbers cannot be exact, although I can imagine a system in which (expt e (* 2 pi)) -> the exact integer 1 and (log e) -> exact 1.
I can think of three reasons of adorning the representation of a number with the predicate inexact: 1: it was produced by a function that cannot compute the exact value in the any available representation within finite memory. 2: it was entered in the program as an approximation (for example a measurement) 3: There is an approximate inexact representation that allows enough precision but enhances speed by using floating point hardware. In Scheme a predicate either returns #f or #t. For me it would be acceptable to have a third truth value #?. Thus, as far as I am concerned, (= 1.0 1.0) might return #?. IIRC in R6RS the condition (let ((x (lambda () '()))) (equal? x x)) -> #t has been dropped. Nevertheless I would like to maintain this condition for numbers: (let* ((x any-expression-producing-a-number) (y x)) (= x y)) -> #t I must say I am rather satisfied with the two (exact and inexact) towers of numeric types in PLT/Racket. It gives you choice between exactness against speed. Furthermore, I think that a programmer who implements arithmetic algorithms may be asked to know what he or she is doing. Jos -----Original Message----- From: plt-dev-boun...@list.cs.brown.edu [mailto:plt-dev-boun...@list.cs.brown.edu] On Behalf Of Joe Marshall Sent: 25 May 2010 18:35 To: Michael Sperber Cc: plt-dev@list.cs.brown.edu Subject: Re: [plt-dev] Inexact integers 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 _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
