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/