A use for integer quotients

[Bengt Richter]

On Mon, 23 Jul 2001 09:12:56 -0700, David Eppstein <eppstein at ics.uci.edu> wrote:
[...]
>think it an improvement.  Integers are exact.  Floating point numbers are 
>approximate.  Integers allow rearrangements like (a+b)+c=a+(b+c), floating 
>point numbers don't.  If you need your numbers to be computed exactly, and 
>your programming language turns them into floats behind your back, it will 
>cause bugs.
<philosophical nit>
IMHO integer and floating point are not comparable concepts. One is an abstract
mathematical concept and the other loosely identifies a set of tricks for
representing numbers in hardware.

    Integer, rational, real, complex

are what need to be represented, with provisions for specifying
and monitoring of how "well" the number is represented. The first
measure of how "well" is exact vs inexact. Exact doesn't need further
qualification. Inexact does, and confusion reigns[1].

    floating point, IEEE754, float, double, extended, short, int,
    long, long long (ick), decimal float, BCD, bi-quinary, string,
    pickling formats, etc., and compounds of same

are different possible representation formats, limited only by imagination.
The integer IV can be represented *exactly* in all those formats ;-).

Exactness is not a property of the representation itself. E.g., Python's float
can represent a bigger contiguous set of integers exactly than its int type
(unless you're on an Alpha or such). Limitations != inexactness, but can
sometimes produce it.

It may be a safe convention to treat floating-point-represented numbers
as inexact, but it is shoddy to mislead newbies by saying that floating
point *is* inexact, implying that even 1.0 should be suspect[2]. It smacks
of the arrogant paternalism that says, "Here's a safe way for you
twits to think about this, so that what you don't know won't hurt you."

OTOH, I think one could argue for hiding the existence of float in a language,
on the grounds that it is a low level implementation detail, and ought not be
visible except to developers and specialists. That's better than outright misleading.
</philosophical nit>

[1] Here we are characterizing the relationship of a pure number (whatever its
    source) to its representation. An exact number per se can result from an
    inaccurate measurement, so people don't like to call such a number exact.
    The word is overloaded. Since representation approximations and measurement
    errors can be compounded into the final result of a computation, people get
    confused about what's what.

[2] An _even_ 1.0 _would_ be suspect ;-)