[plt-dev] Inexact integers

On Tue, May 25, 2010 at 10:59 AM, Jos Koot <jos.koot at telefonica.net> wrote:
> 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.

So true.

> Whatever presentation you select, all machine presentable numbers
> are exact, in principle.

I don't know what this could mean.  You're not suggesting that we could
not represent inexact numbers, I hope.


> 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.

What about log2 of 65536?

> 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.

There are ways of representing pi, e, and other computable reals `exactly'.
One method is to use continued fractions.

> 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.

What do you do in the case that a function that can in many but not all cases
produce an exact value in finite memory?

> 2: it was entered in the program as an approximation (for example a
> measurement)

Why would this matter?  Why would I treat an input approximation
any differently from other numbers?

> 3: There is an approximate inexact representation that allows enough
> precision but enhances speed by using floating point hardware.

What do you do if the floating point hardware can in fact produce correct
exact answers fast?  How can you tell if rounding did or did not occur?

>
> 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.

Yes, but those are orthogonal issues (and not associated with the arguments,
but the operation).


-- 
~jrm