Floating-point to integer conversion and IEEE-754

[Tim Peters]

> [Fred Tydeman]
> Consider the simple assignment:
>
>    i = 1.0e300;   /* Convert floating-point to integer; overflow */
>
> What does IEEE 754-1985 say should happen, in the non-trapping case?
>
> Section 7.1  Invalid Operation
>       (7) Conversion of a binary floating-point number to an integer
>       or decimal format when overflow, infinity, or NaN precludes a
>       faithful representation in that format and this cannot otherwise
>       be signaled.
> ...
> I see three possible results for which exceptions are raised:
>   1)  Invalid operation
>   2)  Overflow and inexact
>   3)  Invalid operation, overflow, and inexact
>
> Comments?

Fred, I agree that the 754 std is awfully hard to decipher in this case.
The answer to your question is "1, maybe; 2 or 3 never".  Quoting from "A
Proposed Radix- and Word-length-independent Standard for Floating-point
Arithmetic" (a 754 rationale doc of sorts, from Aug '84 _Micro_, but it's
been printed in other places too), section 5:

	Floating-point overflow never occurs during conversion to an
	integer because conversion to a floating-point integer (5.5)
	cannot overflow, and conversion to a fixed-point integer (5.4),
	if it overflowed, would have to signal either integer overflow,
	if available, or invalid (7.1).

The baffling "and this cannot otherwise be signaled" clause in 7.1
presumably refers to this "integer overflow, if available" facility,
mentioned in the pseudo-rationale but never in the std proper.  So the
intent appears to be that if you have a way to signal integer overflow
(distinct from the 754-defined overflow flag), i = 1.0e300 should signal
that and leave the 754 flags alone, else signal invalid operation only.

The "1, maybe; 2 or 3 never" answer is thus clear from the pseudo-
rationale, & _consistent_ with the std, but if you were to say that you
couldn't _deduce_ it with confidence from what 754 alone says, I would
agree.


Another interesting case is whether

	i = 2.3;

should signal inexact.  As you quoted 754:

Section 7.5  Inexact
      If the rounded result of an operation is not exact or if
      it overflows without an overflow trap, then the inexact
      exception shall be signaled.

Well, the exact result of integer conversion of 2.3 is clearly 2, which
is the exact value delivered:  no information is lost that the user didn't
explicitly ask be thrown away.  So as I read 754 it should not signal
inexact.  Section 5.4 (float->int conversions) says nothing against this
view, either.  However, the pseudo-rationale clearly says it thinks
inexact should be raised in this case, while section 5.4 of the *8*54 std
contains this additional sentence:

	When no other exception arises, this operation signals inexact
	whenever its result differs in value from its operand.

So the 854 std is clear about this.

when-we-were-implementing-754-we-just-looked-at-what-happened-on-a-sun-
   and-copied-it<0.9-grin>-ly y'rs  - tim

Tim Peters   timaksr.com
not speaking for Kendall Square Research Corp