dgh@sun.uucp (David Hough) (01/10/86)
The following questions have been raised in a posting by S. Issakow. I am responding based on my experience on the IEEE P754 and P854 committees. IEEE arithmetic is specified in ANSI/IEEE Standard 754-1985. > double a, b, c; > [assignment to b and c] > c = a / b; > > 1) If `a' == 1.0 and `b' == 0.0 , should the divide-by-zero cause > a SIGFPE? (on some Unix systems it does not). If a signal > should not be generated, then what value should be > assigned to `c'? > > 2) If SIGFPE is being ignored or caught (perhaps there are two > answers), what value should be assigned to `c'? I suppose the > possibilities are infinity, a NaN, or some random value since > one could claim that dividing by zero produces an undefined result. The default action in IEEE arithmetic is to return the value +Infinity and set the divide-by-zero exception flag. If the optional divide-by-zero trap is implemented and enabled, then a signal should be provided (in a Unix environment, presumably SIGFPE) with means of communicating to the signal handler the following information: 1) which exception occurred 2) what kind of operation was being performed 3) the destination's format {single, double, extended, int, long...} 4) the operand values > 3) If `a' and `b' above both contain infinity, then what should > happen (infinity divided by infinity is a Nan)? Should SIGFPE > be generated in this case? What if it is ignored or caught? The default action is to return a quiet NaN and set the invalid operation exception flag. If the optional invalid operation trap is implemented and enabled, a signal should be provided as above. > 4) If you manage to get the value of infinity or a nan into a > a float or double variable, what should printf(3) do with it > if you pass this value to it? I have seen various Unix systems > deal with this in one of three ways: > a) generate a SIGFPE > b) print a large number (for infinity) > c) go into an infinite loop (usually in ecvt(3)) Printf should generate appropriate ASCII strings when its input is an infinity or quiet nan and by default, when its input is a signalling NaN. When the input is a signalling NaN and the optional invalid operation trap is implemented and enabled, a signal should be provided as above. Appropriate strings are not specified by the IEEE standard; "+Inf", "-Inf", and "NaN" have been used, among others. Whatever strings are chosen should also be recognized correctly on input. The full trapping capability suggested in the IEEE standard has seldom been implemented, involving as it does a rare coordination between persons responsible for hardware, operating system, compilers, and floating point libraries. Systems based on the 80?86/80?87 and 68020/68881 have the hardware support necessary to make the full trapping capability available. Some expansion of the existing Unix signalling facility would probably be necessary to realize the potential. A group at Apple Computer has devoted a lot of thought to these issues in the contexts of C and Pascal. For more information, write to Jim Thomas at Apple and request a copy of the Language Specifications for SANE Numerics. David Hough