# [racket] Multiplying by 0

 From: Jos Koot (jos.koot at telefonica.net) Date: Tue Feb 15 14:06:24 EST 2011 Previous message: [racket] Multiplying by 0 Next message: [racket] Multiplying by 0 Messages sorted by: [date] [thread] [subject] [author]

```(rational? 1.0) -> #t
(exact? 1.0) -> #f

This is in accordance with the docs of Racket.
For myself I would like all numbers to be indicated as exact when possible.
For example, 0.5 is in most reprentations can be represented exactly.
Inexactness can be generated in two ways:
1: Writing down a number in flp format (id est with a period) which does not
exactly a equal counterpart in that representation (for example more decimal
figures than can be ccounted for)
2: Calling a function with an argument for which it cannot produce an exact
result representation, e.g. (sqrt 2).

I think it is a good idea to adorn the result of (sqrt 2) with the property
of inexactness (although it is, of course, possible to represent square
roots of an exact number in an exact way, and to a finite degree we could
even do so for higher order roots)

Now when a user of a program enters 0, that means exactly 0.
When a user enters 0.5, the semantics can be that the number may come from
an experiment with inherent inaccuracy. When the user writes 1/2, that would
be interpreted as an axact rational number.

We may even have exact representations for e and pi, simply by writing them
as 'e' and 'pi'. Another question is what should happen when calculating
(expt e (* #e0+1i 2 pi)). In group theory many numbers are square roots of
(exact) rational numbers. So these numbers can be represented exactly as a
sign followed by the squares of the numbers. Everything is in the
representation. But the fact remains that it is not possible to represent
EVERY arbitrary real (or complex) number exactly within a finite memory.

When using a delicate numerical number system as in Scheme or Racket, the
programmer must be acquainted with the limitations of this system. Making a
tower of numerical representations that seems to follow the intuition of the
programmer is a good thing, except when the programmer does not understand
the limitations of this representation.

Jos

> -----Original Message-----
> From: users-bounces at racket-lang.org
> [mailto:users-bounces at racket-lang.org] On Behalf Of Joe Marshall
> Sent: 15 February 2011 18:53
> To: Hendrik Boom
> Cc: users at racket-lang.org
> Subject: Re: [racket] Multiplying by 0
>
> On Tue, Feb 15, 2011 at 12:22 AM, Hendrik Boom
> <hendrik at topoi.pooq.com> wrote:
> >
> > Yeah, floating point is approximate.
>
> To be very precise and pedantic, floating point consists of
> two things:
>   1.  A selected set of rational numbers along with an associated
>       representation.
>   2.  A variety of well-defined mathematical operations on this set
> with the constraint
>       that the result of the operation must produce a representable
>       number that is mathematically correct if possible, or, depending
>       on the rounding rules, the representable number closest to the
>
> The `approximation' is in the operations, not in the numbers.
>  This implies
> the property that any floating point number (that is, a
> floating point object
> that represents a number.  The weird things like infinities
> and NaNs don't
> count.) can be converted to a rational and back without loss
> of information
> (or `gain of information' --- additional unwarranted bits of
> precision)
>
> If the *number* were approximate, there would be ambiguity about which
> rational it represented.
>
> > That said, it actually provides an
> > exact value
>
> Exactly correct!
>
> > which the user hopes is close to the intended value, but
> > floating-point makes no attempt to assign bounds on how
> > is.
>
> Who knows what the user hopes?  A reasonable person may decide
> to implement fixnums with floating point representation.  The
> results will
> be mathematically correct for addition, subtraction, and
> multiplication
> if the fixnums are kept to fewer than 53 bits of precision
> (for doubles).
> There will be no `rounding error' whatsoever.  (Division is a
> different story,
> but that is an issue with integers, not with the floating
> point representation.)
>
> > Calling floating-point "approximate" is a way of hinting to
> the naive
> > user that the answers may not be quite right.  And
> numerical analysts
> > can easily come up with examples where the answers are grossly,
>
> Right.  But it tends to mislead naive users into thinking
> there is something
> squirrelly about floating point numbers.  The numbers are
> fine, the operations
> are squirrelly.
>
> > To have approximate values that are really logically
> consistent, we's
> > have to use somoething like interval arithmetic, in which the
> > calculation provides lower and upper bounds for the answer.  Then is
> > come calculation produces and answer x like 1e100, you's know the
> > precision.  Is x 1e100 plus-or-minus 1, or is x 1e100 plus-or-minus
> > 1e200?
>
> Or use a distribution function rather than a number.
>
> > In the first case, (min 0 x) coule legitimately be 0.  In
> the second, it
> > would have to be the interval "something between -1e200 and 0"
> >
> > Now this is consistent, and will inform you whether you can
> rely on the
> > answer, becaues it doesn't provide an illusion of precision.
> >
> > Going further, what you might really want for approximate
> arithmetic is
> > for a number to be a function which, when given a tolerance
> 'epsilon',
> > will tield a value within epcilon of the correct answer.  Going this
> > way, you end up with the constructive real numbers.  These are the
> > closest things we can compute with to what most
> mathematicians call the
> > real numbers.  In fact, if you are a constructive mathematician, you
> > will use the phrase 'real numbers' for (equivalence classes
> of) these
> > functions, and you'd consider the idea of real numbers that cannot
> > be expressed this way to be an incoherent fantasy.
> >
> > There.  Now you have an idea how far you can go in this direction.
> > Stopping at floating-point is a matter of efficiency, not conceptual
> > completeness.
>
> --
> ~jrm
>
> _________________________________________________