Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0358 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0358.

Report 0358 Actions

    Problem Report Number 0358
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0010
    Raised 1995-08-29 08:00
    Updated 2003-03-13 08:00
    Published 1995-09-04 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.3.5
    Test Identification XPG4.hdr/misc/float 4
    Specification System Interfaces and Headers Issue 4
    Location in Spec See Problem Text
    Problem Summary TIN4.010 Our original interpretation request (float.01) was refused in req.4.2.485 on the grounds that additional information needed to be provided. We have obtained that information and are resubmitting this ...
    Problem Text
    Our original interpretation request (float.01) was refused in
    req.4.2.485 on the grounds that additional information needed
    to be provided. We have obtained that information and are
    resubmitting this request.

    To: X/OPEN

    >From: Tom MacDonald
    X3J11 Vicechair


    I have read the response from X/OPEN about our implementation of
    <float.h> and I'd like to make the following observations.

    First, I wrote the original description for the <float.h> section
    back in 1985 and I certainly would not have proposed a section
    that eliminates our implementation. The purpose of standards is
    *not* to eliminate commercially successful implementations (like
    ours) but to standardize existing practice and include all
    commercially successful implementations. Thus the C Standard
    carefully chose to grant an implementor considerable latitude in
    defining their floating-point implementation. Committee X3J11,
    the committee that defined the C Standard, understood the diversity
    that exists in floating-point implementations and went out of their
    way to accept them.

    Second, widely used C test suites such as Plum-Hall and Perennial
    agree that our implementation of <float.h> conforms to the C
    Standard and have tailored their test suites accordingly. Both
    Plum-Hall and Perennial are represented on committee X3J11.

    Third, the committees WG14 and X3J11 that accept and respond to
    "Defect Reports" associated with the C Standard have already
    responded to similar questions, on occasion, and have always stated
    that the values defined in <float.h> do not have to match the
    hardware. Furthermore, the C Standard does not even require an
    implementation to have floating-point hardware. The C Standard
    only talks about translators and implementations. The underlying
    machinery can be an interpretor that is completely machine
    independent. It can also be a combination of hardware and software.
    Therefore, a response such as:

    "The first is a claim by the submitter that the values defined in
    <float.h> do not have to reflect the hardware capabilities of the
    implementation. This may be valid for some <float.h> values, but
    not for others."

    is not justified by the C Standard itself. This kind of interpretation
    leads to the rejection of any implementation that supports NaNs,
    Infinities, and Denormal numbers since the C Standard only characterizes
    normalized numbers with its model.

    Subclause 5.2.4.2.2 in the C Standard states that floating-point
    characteristics are defined in terms of "a model that describes a
    representation" and does not say "the model that describes the
    representation." The actual values are a quality of implementation
    issue.

    Part of the response to Defect Report # 025 states:

    "Implementations are allowed considerable latitude in the way
    they represent floating-point quantities; in particular, as
    noted in Footnote 10 on page 14, the implementation need not
    exactly conform to the model given in subclause 5.2.4.2.2 for
    `normalized floating-point numbers.'"

    Again, the C Standards Committee did not intend to tie the hands of
    implementations when defining the most useful values for the
    characteristics present in <float.h>.

    The question arises, why did we choose a value different
    than the hardware values? The answer is that we chose
    values for FLT_EPSILON, DBL_EPSILON, and LDBL_EPSILON that are
    the most useful to application writers. The following is a summary
    of why software values were chosen.

    Our floating-point hardware has an extremely large exponent
    range which means it is highly unlikely that well behaved programs will
    ever approach the hardware limits. Our SW model has been
    chosen as that which is closest to the actual hardware and also meets the
    following criteria:

    1) The reciprocal of the maximum floating point value does not cause
    underflow.

    2) The reciprocal of the minimum floating point value does not cause
    overflow.

    3) Correct results are obtained for the tests described by the
    paper "A Test of a Computer's Floating-Point Arithmetic Unit"
    Computing Science Technical Report No. 89, Bell Laboratories, by
    N. L. Schryer, February 4, 1981.

    In other words, the model must allow all arithmetic operations on
    operands that are within the range of minimum to maximum, inclusive,
    and for which results are, mathematically, also within the range, and
    further, the results must behave reasonably within the ability of the
    hardware to represent the mathematical value.

    This model is defined by 47 bits in the mantissa, 94 bits for double
    precision, a minimum biased exponent of 020003 (octal), and a
    maximum biased exponent of 057776 (octal).

    Any decimal string within the range of minimum to maximum with
    this or fewer significant digits are guaranteed to be convertible from
    decimal string to internal representation and back to the same decimal
    string.

    If the hardware maximum and minimum values are used, then expressions
    such as:

    (FLT_MAX / 2.0f) * 2.0f
    (FLT_MIN * 2.0f) / 2.0f

    cause an exception (overflow) to occur.

    We set our software value of FLT_MANT_DIG to be one less than
    the hardware value because our hardware doesn't support a guard
    bit. This software value provides better behavior when a programmer is
    trying to determine the amount of relative error accumulating in
    floating-point addition (for instance) because a software guard bit is
    present. This leads to the software values found with FLT_EPSILON,
    DBL_EPSILON, and LDBL_EPSILON. Our software values are more
    useful for algorithms seeking convergence of a result that is within the
    tolerance of what the floating-point arithmetic supports. If the hardware
    values of FLT_EPSILON, DBL_EPSILON, and LDBL_EPSILON were used, these
    algorithms would execute more iterations while attempting convergence (but
    yielding a result that is no more useful), and in the process an exception
    might occur (thus causing the program to abort).

    The primary motivation here is to provide an implementation that is useful
    to application programmers. The software values provide more useful
    information than the hardware values. It is clear that a set of tests can
    be derived that compute hardware limits, but are these values the most
    useful? If these values can be derived by clever tests, then why would
    the C Standard require implementations to supply them? The reason the C
    Standard contains <float.h> is because the committee believed implementors
    provide the most useful values.

    We ought to consider what is of greatest benefit to the end user and not
    what information a clever test can derive.

    This is our justification of why <float.h> is implemented the
    way it is. If X/OPEN still believes that values derived from clever tests
    are more useful then we would be interested in hearing about why they are
    considered more useful. That is, who benefits from these values? We
    are also willing to pursue this through the C Standardization
    process though the committee has discussed these issues before and there
    appears to be no committee support for insisting that hardware values
    be mandated by the C Standard. Perhaps a letter from the Chairman of
    X3J11 would be sufficient. Please advise us on what steps we need to
    take next.

    Test Output

    ************************************************************************
    /tset/XPG4.hdr/misc/float/T.float 4 Failed

    Test Description:
    When the values for the following symbolic names can be determined
    arithmetically, then the symbolic names evaluate to the same value:
    FLT_DIG, DBL_DIG, LDBL_DIG, FLT_MIN_EXP, DBL_MIN_EXP, LDBL_MIN_EXP,
    FLT_MIN_10_EXP, DBL_MIN_10_EXP, LDBL_MIN_10_EXP, FLT_MAX_EXP,
    DBL_MAX_EXP, LDBL_MAX_EXP, FLT_MAX_10_EXP, DBL_MAX_10_EXP,
    LDBL_MAX_10_EXP, FLT_MAX, DBL_MAX, LDBL_MAX, FLT_EPSILON, DBL_EPSILON,
    LDBL_EPSILON, FLT_MANT_DIG, DBL_MANT_DIG, LDBL_MANT_DIG, FLT_MIN,
    DBL_MIN, LDBL_MIN and FLT_RADIX.

    Test Information:
    Feature test macros: -D_XOPEN_SOURCE
    Compiler or run-time messages or results:
    Value of FLT_MIN_EXP is incorrect
    Observed: -8189
    Expected: -8192
    Value of FLT_MIN is incorrect
    Observed: 3.66720773511e-2466
    Expected: 0
    Value of FLT_MIN_10_EXP is incorrect
    Observed: -2465
    Expected: -2466
    Value of FLT_DIG is incorrect
    Observed: 13
    Expected: 14
    Value of FLT_MANT_DIG is incorrect
    Observed: 47
    Expected: 48
    Value of DBL_MIN_EXP is incorrect
    Observed: -8189
    Expected: -8192
    Value of DBL_MIN is incorrect
    Observed: 3.66720773511e-2466
    Expected: 0
    Value of DBL_MIN_10_EXP is incorrect
    Observed: -2465
    Expected: -2466
    Value of DBL_DIG is incorrect
    Observed: 13
    Expected: 14
    Value of DBL_MANT_DIG is incorrect
    Observed: 47
    Expected: 48
    Value of LDBL_MIN_EXP is incorrect
    Observed: -8189
    Expected: -8192
    Value of LDBL_MIN is incorrect
    Observed: 3.66720773510972502543901904e-2466
    Expected: 0
    Value of LDBL_MIN_10_EXP is incorrect
    Observed: -2465
    Expected: -2466
    Value of LDBL_DIG is incorrect
    Observed: 27
    Expected: 28
    Value of LDBL_MANT_DIG is incorrect
    Observed: 94
    Expected: 96
    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The issue of whether the values defined in <float.h> are required to
    reflect the hardware capabilities of the implementation has apparently
    already been clarified in defect report 025, and so this is no longer
    a concern.

    The second issue, regarding the relationship between FLT_EPSILON and
    FLT_MANT_DIG, still needs to be addressed. The test suite reported a
    value for FLT_MANT_DIG, but did not report one for FLT_EPSILON.
    There are two possible reasons for this: 1. the test suite calculated
    one of the two values incorrectly, or 2. the implementation does not
    define these values such that FLT_EPSILON is equal to FLT_RADIX raised
    to the power of (1 - FLT_MANT_DIG). The submitter was asked to supply
    these values (and the corresponding DBL and LDBL values), so that the
    relationship can be checked. However, these values have not been
    supplied, and so the question remains.

    It is recommended that a Temporary Interpretation is granted, pending
    further information from the submitter. If the submitter can confirm
    that the value of FLT_EPSILON is equal to FLT_RADIX raised to the power
    of (1 - FLT_MANT_DIG), and likewise for the corresponding DBL and LDBL
    values, then the Temporary Interpretation should be converted to a
    Permanent Interpretation. If not, then it should remain a Temporary
    Interpretation, and an interpretation of the C standard should be sought
    as to the requirements it makes on the relationships between the values
    defined in <float.h>.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Temporary Interpretation (TIN)
    Review Conclusion
    A Temporary Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority