From willemw@komp Thu Sep 4 16:13:01 1997 Received: from komp.ace.nl (komp.ace.nl [193.78.104.90]) by dkuug.dk (8.6.12/8.6.12) with SMTP id QAA09193 for ; Thu, 4 Sep 1997 16:13:01 +0200 Received: by komp.ace.nl with SMTP id AA27730 (1.14/2.17); Thu, 4 Sep 97 16:11:14 +0200 (MET) To: sc22wg11@dkuug.dk Subject: WG11 N440 (2 of 7): LIA-1 binding for C: Pole from LIA-2 Date: Thu, 04 Sep 97 16:11:13 N Message-Id: <27728.873382273@komp> From: Willem Wakker 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 ================ 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 - --- Fred J. Tydeman +1 (512) 255-8696 Tydeman Consulting 3711 Del Robles tydeman@tybor.com Programming, testing, numerics Austin, Texas 78727 Voting member of X3J11 (ANSI "C") USA Sample C9X+FPCE tests: ftp://jump.net/pub/tybor/