[plt-dev] Inexact integers

My remarks: see ===

-----Original Message-----
From: eval.apply at gmail.com [mailto:eval.apply at gmail.com] On Behalf Of Joe
Marshall
Sent: 25 May 2010 20:46
To: Jos Koot
Cc: Michael Sperber; plt-dev at list.cs.brown.edu
Subject: Re: [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.

=== This is a matter of definition of exact an inexact. Within the hardware
everything is exact as long as not exceeding limits of memory. This does not
imply that the things represented by the hardware are exact. This decision
is to be made y the programmer.


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

=== That depends on representation of numbers and the implementation of
log2.

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

=== That is a very good question. I am afraid this is an unsolvable
question. We already know that some questions cannot consistently be
answered by mathematics.

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

=== Because in this case two entries that consist of the same characters
figures cannot be trusted to be equal in exact sense.

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

=== This is a non issue I think. Where we can, we should within practical
limits compute exactly, but once leaving exactness, the question whether or
not a result is exact is  not relevant. The representation of the result
should indicate whether or not he answer is certainly exact or may be
inexact.

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

=== True!!!!


-- 
~jrm