JTC1/SC22/WG14
N748
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