Comments on NCEG paper X3J11.1/92-040 Floating-Point C Extensions

[Fred Tydeman]

Vote:  Yes, with comment.
 
The following are IBM's comments to be included with the X3 subgroup
letter ballot on X3J11.1/92-040.
 
A general comment based upon 26. Miscellanea compiled by Rex Jaeschke
pages 248-249, The Journal of C Language Translation, Volume 3, Number 3,
December, 1991.  All dummy argument identifier names used in the
Standard are non-conforming!  Essentially, these identifiers must
either be omitted, spelled with a leading underscore and a capital
letter, or with two leading underscores.  Therefore, you need to change
all your function prototypes.  IBM votes for adding "__" to the names.
To see why the current prototypes fail, consider:
  #define x 3
  #include <math.h>
  #define stream 3
  #include <stdio.h>
 
A second general comment:  The Floating-Point Environment is not well
defined and is incomplete.  From section 4.4 Floating-Point Environment,
fesetexcept and fesetenv set, but not raise, exceptions.  Therefore, set
cannot mean the same thing as raised.  Therefore, there must be at least
3 states (set, raised, cleared) for each exception.
 
Since 3-state is hard to do on a binary machine, it appears that each
exception has associated with it:
 1)  Set or cleared
 2)  Raised or not raised
 3)  Trap enabled or disabled
 4)  Optional information, such as:
    a) Address of the code which raised it
 
Given that a distinction has been made between set and raised, the
functions in section 4.4 are not complete.  There is no way to test what
exceptions are currently raised.  There is no way to remove a raised
exception.  The only way to restore the entire floating-point
environment is to feclearexcept(FE_ALL_EXCEPT); followed by
feupdateenv(&save_env);
 
One issue not addressed is how long is an exception raised?
 
Now, for the specific comments.
 
Page 4, line 37, Section 1.5 Definition of Terms, refers to "status
    flags" and "control modes", yet neither are defined.  So, the next
    items are needed.
 
  Page 4, line 9, need to add something like:
    Control modes -- variables that the user may set, sense, save, and
    restore to control the execution of subsequent arithmetic
    operations.  Floating-point control mode is made up of at least the
    rounding direction mode and the rounding precision mode.  An
    implementation may also have traps disabled/enabled modes (which is
    not covered by this specification).
 
  Page 4, line 51, Mode:
    Add at end of sentence: See control modes.
 
  Page 5, line 32, need to add something like:
    Status flag -- a flag signifying that a floating-point exception has
    occurred since the user last cleared it (each flag may take three
    states:  set, raised and clear).  When not cleared, a status flag
    may contain additional system-dependent information, possibly
    inaccessible to some users.  IEEE implementations support overflow,
    underflow, invalid, divide-by-zero, and inexact status flags.
 
    Another choice for this is status flags is made up of exception
    flags (raised/not raised) and 'sticky' accrued flags (set/cleared).
 
Page 6, line 5, Section 2 Environment:
    What is "enabling"?  IBM assumes it is "on" or "default" where
    "default" is "on".
 
Page 26, line 7, Section 4.2.1.2 The strtof, strtod, and strtold
functions:
    Is an implementation that supports sign-opt NANS(n-char-sequence-opt)
    or sign-opt NANS, for signaling NaNs, in violation of this standard?
    If so, than these two syntax forms need to be added.  If not, then a
    note should be added after line 38 on page 26 explaining that
    implementations may be extended to support signaling NaNs, and that
    the above is the syntax.  NCEG should at least standardize the syntax
    of signaling NaNs.
 
Page 32, line 14, Section 4.3 Floating-Point Extensions <fp.h>
    What type (float, double, long double) does DECIMAL_DIG refer to?  I
    assume that  it is the widest  supported based upon the examples. It
    may be better to change line 14  to:  between decimal and the widest
    supported internal floating-point representations.
 
Page 40, line 26, Section 4.3.4.12 The scalb function
    Change 'long int' to 'int'.
 
    ldexp computes x * 2**exp
 
    scalb computes  x * FLT_RADIX**exp,  where FLT_RADIX is  most likely
    one of 2, 8, 10, or 16.
 
    Since the base used in scalb is  never smaller than 2, the base used
    in ldexp, it seems logical that the power (exp) will never be larger
    than the  power used  in ldexp  (unless overflow  or underflow  will
    happen).
 
    Hence,  it appears  that  exp  should have  the  same  type to  both
    functions.
 
    Now, is int big enough?
 
    For most micros, where int is  often only 16-bits, IEEE-754 floating
    point is used.   The exponent range  of IEEE-754 double is  -1021 to
    +1024, so a 16-bit int is large enough.
 
    On the other hand, there are  computers where the exponent range can
    go as low as -32896 (Prime 50 Series) and as large as +32780 (Unisys
    "A Series").   But  on those  machines, I  believe int  is typically
    32-bits, so again, int is large enough.
 
    Note:  The exponent ranges came from Annex F (Typical Floating Point
    Formats) from LIA Part 1:  Integer and floating-point arithmetic.
 
Page 47, lines 15-16, Section 4.3.9.2 The nan functions:
    Swap these two lines, so the float comes first.
 
Page 52, line 26, Section 4.4.1.3 The feraiseexcept function:
    Please add the following in smaller font size as a note:
    It is possible that if an enabled trap is taken, the feraiseexcept
    function will not return, as the trap handler may have altered the
    flow of control by say a longjmp.
 
Page 52, line 48, Section 4.4.1.4 The fesetexcept function:
    Change "must" to "should".
 
Page 59, line 5, Section B.1 Expression evaluation:
    What is the rational for that statement?
 
Page 59, lines 39-42, Section B.2 Expression transformations:
    Unfortunately, the statement "y = x - 0;" cannot be transformed into
    "y = x;" as per your argument, because if x is a signaling NaN, x - 0
     will trigger it, whereas the simple assignment need not trigger it.
 
Page 66, line 23, Section F. <fp.h> for IEEE Implementations:
    Change 'is' to 'should be' or 'is probably'.  IBM would like to
    allow inexact to not be raised in some cases.  That is, we would
    like inexact to probably be raised when it should be raised.
 
Page 66, line 40, Section F. <fp.h> for IEEE Implementations
    Does "appends to" mean that errno support is required?  I believe
    that NCEG wants errno support removed or optional.  But, I am
    afraid that someone may interpret this area as still requiring
    support for errno.
 
Page 72, line 10, Section F.4.3 The pow function:
    Add rational for why pow(+1, +/- INFINITY) is NaN, instead of +1.
 
Fred Tydeman, IBM, Austin, Texas (512) 838-3322; fax (512) 838-3484
AIX S/6000 Math library architect & IBM's rep to NCEG (X3J11.1)
Internet: tydemanaibmpa.awdpa.ibm.com    uucp: uunet!ibmsupt!tydeman