Document Number: WG14 N748/J11 97-111 Title: LIA-1 Binding: Adding 'pole' from LIA-2. Author: Fred J. Tydeman In doing research for the LIA-1 binding for C9X, I found the following email that discusses adding the 'pole' exception from LIA-2 to LIA-1. I believe that this should be included in a mailing. I plan on adding parts of this to the rationale. ================ Date: November 26, 1996 To: X3T2 Chair is: Tony Sarris (tony@ontek.com) was: Craig Schaffert (schaffert@crl.dec.com) when we sent the question. From: Rex Jaeschke, X3J11 Chair rex@aussie.com Subject: Request for Interpretation Does Language Independent Arithmetic Part 1 (LIA-1) require that we can't distinguish between poles and other undefined exceptions? Background A pole exception is the same as a divide-by-zero exception: a finite non-zero floating-point number divided by a zero floating-point number. Currently, various standards define the following exceptions for the indicated sample floating-point operations. For LIA-2, there are other operations that produce the same exceptions. LIA <----------- Standard -------------------> IEEE Exception LIA-1 LIA-2 IEEE-754/IEC-559 Exception undefined 0.0 / 0.0 sqrt(-1.0) 0.0 / 0.0 invalid 1.0 / 0.0 log(-1.0) infinity / infinity infinity - infinity 0.0 * infinity sqrt(-1.0) pole (not yet) log(0.0) 1.0 / 0.0 division by zero floating_ max * max exp(max) max * max overflow overflow max / min max / min max + max max + max underflow min * min exp(-max) min * min underflow min / max min / max In the above table, 1.0/0.0 is a shorthand notation for any non-zero finite floating-point number divided by a zero floating-point number; max is the maximum floating-point number (FLT_MAX, DBL_MAX, LDBL_MAX); min is the minimum floating-point number (FLT_MIN, DBL_MIN, LDBL_MIN); log() and exp() are mathematical library routines. We believe that LIA-1 should be revised to match LIA-2, IEC-559 and IEEE-754 in that 1.0/0.0 should be a pole exception and 0.0/0.0 should be an undefined exception. Standards referenced ISO/IEC 10967-1, First edition, 1994-12-15, Information technology -- Language independent arithmetic -- Part 1: Integer and floating point arithmetic. Also known as LIA-1. ISO/IEC 10967-2, working draft, 1995-11-30, Information technology -- Language independent arithmetic -- Part 2: Elementary numerical functions. Also known as SC22/WG11 N 424 and LIA-2. CEI/IEC 559, Second edition, 1989-01, Binary floating-point arithmetic for microprocessor systems. Also known as IEC-559. ANSI/IEEE Std 754-1985: Standard for Binary Floating-Point Arithmetic. Also known as IEEE-754. ================ I, Randy, decided to ask Mary Payne (a central figure in the development of LIA) for her opinion on the pole issue in LIA-1. Her reply struck me as very sensible. She's given me permission to forward it to the C reflector. From: HPCGRP::PAYNE 3-OCT-1996 12:02:00.50 To: DECC::RMEYERS CC: @HARRIS,@CRAIG,PAYNE Subj: Poles in LIA Hi Randy, The possible inconsistency on "poles" between LIA-1 and LIA-2 is troublesome, and I am not sure that I have real answer at present. However, I do have a suggestion, given below. First, I consider it likely that there will be other such problems, for example the specifications for defining and reporting other "error conditions." My present bias is that a record should be kept of such possible inconsistencies as LIA-2 and LIA-3 are developed. When all three are complete, they could then be examined for how best to reconcile these inconsistencies. It would, of course, be undesirable to introduce changes in any of the three which would invalidate such implementations as are in effect. It is also undesirable to adopt any policy which might inhibit implementation of the earlier parts of the standard while later parts are still under development. To conclude, I would recommend that an effort be made during the development of LIA-2 and LIA-3 to minimize the inconsistencies among the various parts. Then, when all three are complete, for each remaining inconsistency seek specifications for a consistent set to be added as an alternative to the earlier inconsistent specifications. Does this help? Mary ================ Calling the lack of differentiation of the pole exception in LIA-1 an "error" is silly - "up the pole" to use an old-fashioned English expression. It was a design decision not to differentiate it. Someone looking at it from a different perspective might regard it as a wrong decision, WG11 (or SC22 or JTC1 who also approved LIA-1) might now with hindsight think it a wrong decision, but that doesn't make it an error. This matters only because, if it really were an error we could issue a Technical Corrigendum to fix it. Since it isn't an error we can't. We could either go for an amendment, which means going through a load of votes, or opt for "revision" when the next review comes up, and fix it then. My personal preference is for the latter. I don't see that this "design weakness" (!) is that serious because there's nothing to stop those who want to distinguish the pole kind of undefined from so doing. There's one thing we might note from this. We decided to do LIA-1, -2, -3 consecutively, not in parallel. If we'd done them in parallel, or in "echelon" - i.e. start LIA-2 when LIA-1 goes for CD registration ballot, etc - this might have been picked up before LIA-1 was finalised. The questions that Kent has been raising about the definitional methods might have been picked up as well. But for resource reasons we didn't, a quite justifiable decision from that point of view, but with the effect that we have an LIA-1 which does not wholly take into account the needs of the later parts. Brian Meek ================ Brian, May I forward your response to the C language standards email reflector? Is anything being done to get the word out to the various language committees that the published behaviour in LIA-1 may not be the best and that it most likely will change in the future, eg, so that the language committees adopt the preferred behaviour? --- Fred J. Tydeman ================ Yes, by all means copy what I said to WG14. As for your query (...in LIA-1 may not be the best...), that would be better addressed to Willem Wakker as WG11 convenor. My personal view is that it's risky to say things like "most likely to change in the future" because it's hard to predict what future committees and ISO member bodies might do! The way to get it on the record is to make a formal 'interpretation request' which then has to be answered on the record. Someone might ask "does LIA-1 mean that we can't distinguish between poles and other undefined, because we think that ought to be done" and the response may be "you can make the distinction if you need to, LIA-1 doesn't preclude it' (as I said) 'and if you wish the issue can be recorded as an item for consideration at the time of revision". Brian Meek ================ Remember that the IS and DIS versions of standards are copyrighted by ISO and should be used for standards development and evaluation purposes only. LIA-1 and LIA-2 are available via anonymous FTP from: crl.dec.com in: pub/misc/lia-1-is.ps.Z pub/misc/lia-2-wd.ps.Z and web access from: http://www.maths.warwick.ac.uk/c++/lia/ But, note, the LIA-2 version on both of those is downlevel. They have First edition Working Draft, November 30, 1995. Current is Second Committee Draft, December, 1996. The latest version may be obtained from the convenor of WG11, Willem Wakker <willemw@ace.nl> ================ My conclusion on mathematical exceptions (which includes the integer and floating-point arithmetic, and the math library), is that exceptions should be partitioned into the following exception types: INVALID invalid or undefined operation or bad argument to operation POLE finite non-zero divided by zero or pole of mathematical function, such as log(0) OVERFLOW finite result so large in magnitude that it cannot be represented without extraordinary roundoff error UNDERFLOW finite result so small in magnitude that it cannot be represented without extraordinary roundoff error APPROX finite result can be represented, but the error between the computed result and the true result exceeds the allowed error for the operation. Large errors may result from arguments too big to the trig functions. INEXACT non-zero error between computed result and true result is within error bounds of the operation; IEC-559 inexact by itself. This exception should not (by default) cause a LIA notification unless the user specificly asks for such notification. In addition, there should be an indication of the general type of the result that would include: floating-point, integral, and decimal character strings. Together, the exception type and the result type indicate the LIA-1 and LIA-2 non-numeric exception value. But, due to the wide variety of hardware, I believe that there should be some leeway on this. Some examples: Conversion of a large floating-point value to integral raises invalid on IEC 559 systems (as a fallback position), but should raise (integral) overflow by the above. Zero / zero should raise invalid and finite non-zero / zero should raise divide by zero by the above. IEC 559 systems can do that for floating-point, but many other systems treat them both as (floating-point) divide by zero. Many systems treat integer zero / zero and non-zero / zero the same: (integer) divide by zero. IBM S/360 treats integer overflow due to divide as (integer) divide by zero. Gould (Encore) PowerNode treats both floating-point and integer overflow as the same. In the math library area, C9X has discovered that existing practice has conflicts on certain error conditions. In particular, ilogb(0) is defined in one place as MIN_INT and in another place as -MAX_INT. So, C9X adopted the solution: ilogb(0) returns FP_ILOGB0, an implementation defined value that shall be either MIN_INT or -MAX_INT. In LIA-1 terms, that value is the continuation value for the undefined behavior of trying to get the base-r exponent of the value 0. Based upon the differences between hardware and existing practice or standards for the math library, I believe that there should be a means to document the implementation's choice that the user can test in their code for the places where different behavior happens. In summary, I believe that LIA's goal of detecting all the arithmetic failures (exceptions) is good. But, the goal of trying to correctly classify the exception in too much detail will not work. Admit that the classification will be fuzzy (not one-to-one) and give the user a means to find out what the mapping choices are. -- Fred Tydeman