ISO/ IEC 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