At 11:11 -0800 2000/02/24, Andy Gill wrote:
>Now what floor does with Inf is undefined (see page 82 of the H98 report).
>
>The real question is should "floor Inf" return _|_? This is up to the
>specific implementation.
These ambiguities show up because of lack of use of exceptions:
One should fix ones mind as to what algebraic entity one wants to define.
Then operations not falling within this scope should throw an exception.
In these case it is the set of floating numbers. The Inf is not properly
part of this logical entity; it should correspond to an exception called
Inf. (The implementations that use an Inf do so because exceptions where
not available.) In this model floor Inf is just the same unchanged
exception Inf, unless floor decides explicitly to handle this exception.
Alternatively, one can define "projective floating numbers" having an Inf.
Then the first question is what the codomain of floor is: Is it Integer
(without Inf) or "projective Integer" (with Inf).
If the codomain is Integer, then there is no good representation of floor
Inf available, so one should throw an exception. But if the codomain is the
projective Integers, then floor Inf should be Inf, or strictly speaking
floor (Inf :: Floating) = Inf :: Integer
So with a proper focus on those algebraic structures, and with appropriate
use of exceptions, I think those ambiguities can be resolved.
About floating numbers, one could think of defining a type Floating(n)
where n is the precision of the mantissa, and which is using Integer as
mantissa. This would be more pleasing from the mathematical point of view,
but because there is no convenient way of transparently slipping in and out
of the types Float and Double, such a type would in most cases
prohibitively slow with todays computers.
Hans Aberg
