mmm@cup.portal.com (Mark Robert Thorson) (05/24/89)
As near as I can tell, the only difference between 754 and 854 is the treatment of massive overflow and underflow. Massive overflow and underflow are the conditions which result when the result of an operation cannot be expressed as a denormalized number. IEEE arithmetic uses a format in which the exponent is biased (e.g. an exponent of 1 with a bias of 8192 is expressed as 8193). When a result exceeds the range of the exponent, a larger bias is used, and a special code is used to indicate that a "denormalized" result has been generated. If a result exceeds the number range which can be represented by denormalized numbers, the condition known as "massive overflow" or "massive underflow" occurs. Under IEEE standard 754, this condition is indicated by a quiet NaN. (A NaN is a representation for "not a number"; i.e. an error condition.) Under its successor, IEEE standard 854, you have the option of returning a quiet NaN, or +/- infinity or zero. My question is: Is there any program (other than Kahan's test suite) which is sensitive to the treatment of massive underflow/overflow? Related question: How does your programming environment handle IEEE weirdness? What happens when I scale a number, and the number range craps out? Does a trap get invoked? If so, is the trap in the user program or the OS? Does anybody support a programming environment in which the application program can make use of the fancy bits of the IEEE standard?
tim@crackle.amd.com (Tim Olson) (05/24/89)
In article <18721@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: | As near as I can tell, the only difference between 754 and 854 is the | treatment of massive overflow and underflow. No, the 854 standard is the radix-independent version of the 754 standard. | IEEE arithmetic uses a format in which the exponent is biased (e.g. an | exponent of 1 with a bias of 8192 is expressed as 8193). Except that (under 754) the biases are +127 for single-precision and +1023 for double-precision. | When a result exceeds the range of the exponent, a larger bias is used, | and a special code is used to indicate that a "denormalized" result has | been generated. Things seem to be a bit confused, here. Denormalized numbers are numbers that are smaller (in magnitude) than those that can normally be represented by the standard biased exponent. Their representation is an exponent (biased) of 0 with a non-zero fraction. This allows "gradual underflow" instead of "sudden underflow", but does result in a loss of precision. You may be thinking of the specification for trapped operation on overflow, which requires that the implementation deliver to the trap handler the result "obtained by dividing the infinitely precise result by 2**_a_ and then rounding. The bias adjust _a_ is 192 in the single, 1536 in the double...". Underflow is the same, except that the number is obtained by multiplying by 2**_a_. | If a result exceeds the number range which can be represented by denormalized | numbers, the condition known as "massive overflow" or "massive underflow" | occurs. | | Under IEEE standard 754, this condition is indicated by a quiet NaN. | (A NaN is a representation for "not a number"; i.e. an error condition.) Not so. The standard says that non-trapped overflow returns either the infinity of the correct sign, or the format's most negative or positive number, depending upon the rounding mode in effect. Non-trapped underflow returns either 0, a denormalized number, or the format's most smallest negative or positive number, depending upon the rounding mode in effect. | Under its successor, IEEE standard 854, you have the option of returning a | quiet NaN, or +/- infinity or zero. No -- same as above. -- Tim Olson Advanced Micro Devices (tim@amd.com)
khb%gammara@Sun.COM (gammara) (05/25/89)
In article <18721@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: > Tim did a good job of clarifying the differences between 754 and 854. >Related question: How does your programming environment handle IEEE weirdness? >What happens when I scale a number, and the number range craps out? Does a >trap get invoked? If so, is the trap in the user program or the OS? Does >anybody support a programming environment in which the application program >can make use of the fancy bits of the IEEE standard? With SunOS and compilers (available from Phoneix, Lachman and Sun) ieee arithmetic is handled "naturally". If you scale a number and underflow occurs, your result is a denormalized number (presuming defaults haven't been tampered with :>). On machines where the hw does this, it does it (viz. 386i, 68K w/o FPA). On machines where denormalized numbers are not handled by the hardware, the computation takes place via a OS trap (SPARC, 3/FPA, 3/FPA+). Overflow results in +- Inf as mandated by your computation. Library routines are provided to check for NaN, Inf, changing the rounding mode, toggling underflow handling (one can have the hw to flush to zero instead of gradual underflow), and setting up user exception handlers. The Floating Point Programmers guide, its addendum, the mathlibrary and f77 man pages explain how to use ieee arithmetic features in user code. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
jimv@pzbaum.uucp (Jim Valerio) (05/29/89)
In article <18721@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson)
asks some questions about exception handling under the IEEE 754 and IEEE 854
floating-point standards.
I am not aware of any application programs that care about how you handle
returning a default exception result for massive overflow or underflow.
I strongly recommend that IEEE trap handling be available to the application
program, because that is the only environment that has the contextual
knowledge to know whether the exception is fatal, can be worked around,
or can be ignored.
I believe that IEEE 854's permission to return an infinity or zero in the
case of massive overflow or underflow, rather than IEEE 754's QNaN, was an
attempt to correct a perceived mistake in the 754 exception handling. If
you need to choose a result here, I recommend returning the infinity or
zero result, and not the QNaN.
I understand that there is a review of IEEE 754 coming up in the next few
years. Personally, I'm looking forward to arguing for a number of modest
changes, including:
(1) Replace subnormal/denormal numbers by a single value (call it epsilon
or infinitesimal), and define arithmetic underflow in terms of this
limiting value.
(2) Remove bias adjusted results for trapped overflow and underflow, and
always return either infinity or epsilon when overflow or underflow
occurs.
--
Jim Valerio jimv%pzbaum@omepd.intel.com, {omepd,reed,radix}!pzbaum!jimvkhb@gammara.Sun.COM (gammara) (05/31/89)
In article <6@pzbaum.uucp> jimv@pzbaum.UUCP (Jim Valerio) writes: > >I believe that IEEE 854's permission to return an infinity or zero in the >case of massive overflow or underflow, rather than IEEE 754's QNaN, was an >attempt to correct a perceived mistake in the 754 exception handling. If >you need to choose a result here, I recommend returning the infinity or >zero result, and not the QNaN. 754 machines return denormalized numbers for underflow ... not QNaN. Massive overflow yeilds +- inf not QNaN. 0/0 yeilds NaN. > >I understand that there is a review of IEEE 754 coming up in the next few >years. Personally, I'm looking forward to arguing for a number of modest >changes, including: > (1) Replace subnormal/denormal numbers by a single value (call it epsilon > or infinitesimal), and define arithmetic underflow in terms of this > limiting value. > (2) Remove bias adjusted results for trapped overflow and underflow, and > always return either infinity or epsilon when overflow or underflow > occurs. >-- for 32-bit machines the subnormization process is a good thing (if one cares about getting the right answer). For better or worse, most folks don't care about getting it right; or if they do they use 64-bit math. Kahan has been pitching a pre-substitution scheme. Those interested should contact him for details. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
wendyt@pyrps5 (Wendy Thrash) (05/31/89)
In article <6@pzbaum.uucp> jimv@pzbaum.UUCP (Jim Valerio) writes: >I understand that there is a review of IEEE 754 coming up in the next few >years. Personally, I'm looking forward to arguing for a number of modest >changes, including: > (1) Replace subnormal/denormal numbers by a single value (call it epsilon > or infinitesimal), and define arithmetic underflow in terms of this > limiting value. Without going into the merits of Jim's suggestion, I'd like to point out that it could hardly be considered to be a _modest_ change. Whether it would enhance 754 (by making hardware easier to build) or cripple it (by removing a useful feature) (and, if both, which is more important) is something that will certainly be debated at length during the review.
dik@cwi.nl (Dik T. Winter) (05/31/89)
In article <6@pzbaum.uucp> jimv@pzbaum.UUCP (Jim Valerio) writes: > (1) Replace subnormal/denormal numbers by a single value (call it epsilon > or infinitesimal), and define arithmetic underflow in terms of this > limiting value. One of the nice things of denormalized numbers is that addition and subtraction cannot underflow. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax