On 15-Mar-2000, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> 2. George Russell pointed out that floor(Inf) and floor(NaN) are not
> defined in Standard Haskell; indeed GHC and Hugs have different behaviour.
> Alternatives
> (A) Make it explicit that the behaviour in these circumstances
> is undefined, so that impls may differ
> (B) Specify that floor should fail (i.e. give rise to a call to
> error)
> (would this have an performance penalty?)
> This is what SML does
>
> I'm inclined to do (A) because it binds impls less, and because it is
> in effect what the report currently says. But I might yield to
> a determined attack in favour of (B).
In the absence of any compelling arguments otherwise, I would on general
principles recommend doing whatever the LIA ("Language Independent
Arithmetic") standard says.
However, this is unfortunately easier said than done!
I have ISO/IEC 10967-1 (LIA Part 1 -- Integer and Floating Point Arithmetic)
in front of me, but the floor function is covered in ISO/IEC 10967-2 (LIA Part
2 -- Elementary numerical functions), of which I have only a five-year-old
working draft. The 10967-2 WD says
| 15.1 FLOOR_{F->I} - Convert to integer (round toward -infinity).
| ...
| FLOOR_{F->I}(+ infinity) = _undefined_
| FLOOR_{F->I}(- infinity) = _undefined_
But here _undefined_ does not simply mean that the behaviour
is undefined; it is an LIA-defined term set in bold font and has a
special meaning. An _undefined_ result denotes an exceptional value
which when returned causes an _undefined_ notification.
One possible result for a notification is for the system
to raise an exception. Another possibility is for it to
set some global flags and to then return a continuation value.
| 6.1 Continuation values
| ...
| For an _undefined_ notification, the continuation value
| shall be a quiet NaN.
For FLOOR_{F->I}(NaN), the result is defined as a NaN:
| 6 Notification
...
| If any operation specified in this part of ISO/IEC 10967 is passed
| a signalling NaN as an input, then an _undefined_ notification shall
| result.
|
| If any operation specified in this part of ISO/IEC 10967 is passed
| a quiet NaN as an input, then no notification occurs and the result
| of the operation is a quiet NaN
...
But in both cases this doesn't really make much sense to me,
since here the result type of the operation is an integer rather
than floating point type. I guess the earlier part of 6.1 does
shed a little extra light:
| 6.1 Continuation values
|
| Continuation values of -0, +infinity, -infinity, and NaN
| are required only if the implementation can represent
| such non-numeric values in the result type.
Well, in this case the implementation clearly can't represent
such non-numeric values in the result type. So I'm not sure
what, if any, requirements LIA-1 and LIA-2 impose in this case.
It appears that they do not impose any requirements.
But I'm not very sure about this, and my LIA-2 draft is very
out-of-date. I think an LIA guru is needed ;-)
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
