Document: WG14 N1550

Possible errors in DFP document N1312


Submitter: Fred J. Tydeman (USA)
Submission Date: 2010-12-22
Subject: Possible errors in DFP document N1312

  1. Existing items in the Decimal Floating-Point (DFP) Technical Report (TR) that might need changing.

    1. Section 3 [Predefined macro name] is missing "Suggested changes to C99".

    2. In section 5 [Characteristics of decimal floating type <float.h>] where it talks about C99 5.2.4.2.2a, paragraph 6:

      DEC*_EPSILON values: I believe that they should have 6/15/33 trailing zeros to get full precision.

      DEC*_MIN values: I believe that they should have 6/15/33 trailing zeros to get full precision.

    3. In section 5 [Characteristics of decimal floating type <float.h>] in the section on __STDC_WANT_DEC_FP__, we need to add "first" before "included".

    4. Section 6.1 [Conversions between decimal floating and integer] is missing:

      Whether conversion of non-integer floating values whose integral part is within the range of the integer type raises the ''inexact'' floating-point exception is unspecified.

    5. Section 7 [Constants] where it talks about C99 6.4.4.2#5, is missing:

      Decimal floating-point constants shall be correctly rounded.

    6. In section 7.1.1 [The FLOAT_CONST_DECIMAL64 pragma] should the pragma be renamed to DOUBLE_CONST_DECIMAL64 (as it only applies to unsuffixed double constants; not all floating constants)?

    7. Add to section 7.1.1 [The FLOAT_CONST_DECIMAL64 pragma] in the section that talkes about C99 6.4.4.2a:

      This pragma has no effect on hexadecimal floating constants.

    8. islessgreater needs to be added to section 8.2 [Functions].

    9. quantexp needs to be added to section 8.2 [Functions]. Actually, does it make sense to list quantize, quantexp, and samequantum since there is no non-decimal floating-point type versions of them?

    10. In section 9.1 [Standard headers] in the section on __STDC_WANT_DEC_FP__, we need to add "first" before "included".

    11. Add to section 9.2 [Floating-point environment <fenv.h>] where it talks about C99 7.6 [7a] about FE_DEC_* macros

      The macros expand to integer constant expressions whose values are distinct nonnegative values.

    12. Section 9.3 [Decimal mathematics <math.h>] in talking about C99 7.12.6.4 frexp mentions "normalized fraction". What does that mean for DFP? What cohort?

      Also, in frexp(x,&ex) and x is a subnormal number, what cohort is the result?

    13. In section 9.4 [New <math.h> functions] should the return type of samequantum*() be changed from _Bool to bool? _Bool is unknown to C++, while bool is known to both C and C++.

    14. Major work needs to be done to section 9.8 [Type-generic macros <tgmath.h>]

      Are quantize*(), samequantum*(), quantexp*() supposed to be type generic? If yes, with what name? Perhaps, the name one gets if they remove the d32, d64, d128 suffixes? Also, C99 7.22 will need words to talk about d32, d64 and d128 suffixes, and functions with _Decimal64 generic parameters.

      Assuming *quant*() functions are type generic, three distinct cases need to be covered (instead of just than one in N1312).

      The reason for two more cases is to cover: 

      remquo( 2.DF/3.DF, 5.DD/7.DD, &i )     /* all DFP arguments to BFP function */
remquo( 5, 7, &i )                     /* all integer arguments */
quantize( 2.f/3.f, 5.0/7.0 )           /* all BFP arguments to DFP function */
quantize( 5, 7 )                       /* all integer arguments */

      One possible set of words is:

      1. For functions that have a double version, but not a _Decimal64 version (such as remquo), then,

        If there is more than one real floating type arguments, usual arithmetic conversions are applied to the real floating type arguments so that they have compatible types. Then,

        -- If any argument has type long double or _Decimal128, the type determined is long double.

        -- Otherwise, if any argument has type double or _Decimal64, or if any argument has an integer type, the type determined is double.

        -- Otherwise, if any argument has type float or _Decimal32, the type determined is float.

        -- Otherwise, the specification in C99 7.22 paragraph 3 applies.

      2. For functions that have a _Decimal64 version, but not a double version (such as quantized64), then the type generic name is the name with the d32/d64/d128 suffix removed, and,

        If there is more than one real floating type arguments, usual arithmetic conversions are applied to the real floating type arguments so that they have compatible types. Then,

        -- If any argument has type _Decimal128 or long double, the type determined is _Decimal128.

        -- Otherwise, if any argument has type _Decimal64 or double, or if any argument has an integer type, the type determined is _Decimal64.

        -- Otherwise, if any argument has type _Decimal32 or float, the type determined is _Decimal32.

        -- Otherwise, the specification in C99 7.22 paragraph 3 applies.

      3. For functions that have both a double and a _Decimal64 version, then ... [existing DFP TR words]

      Another idea is to have DFP argument to BFP function and/or BFP argument to DFP function be undefined behaviour or a constraint violation.

    15. Remove from the index: translation time data type, 13

  2. Items missing from the DFP TR.

    1. The paper needs to mention that C99 F.7.2 Translation, paragraph 1, first item should be changed along the lines of:

      -- The rounding direction mode for both generic floating types and decimal floating types is rounding to nearest.

    2. Due to quantum exponents and possible multiple representations of the same value, transformations ("optimizations") involving zero and one are not safe. Need more words for C99 F.9.2 Expression transformations. In particular, x-0, 1*x, x/1 cannot be changed to x.

    3. A tip of the iceburg issue: C99 F.10.* has requirements along the lines of "acos(1) returns +0" for many functions. Now, for DFP, there are many representations (cohorts) of the value zero. So, what cohort should these kinds of cases have? IEEE-754-2008 punted on this issue (they say the preferred quantum is language-defined). We could leave it as either unspecified or implementation defined. Or, we could leave this issue to the C Floating-Point group that is writing a document about C and IEEE-754-2008.

    4. Related to previous issue: Does ldexpd64(0.0DD,1) have the same cohort (quantum exponent) of the zero argument?

    5. There are no functions to convert between the two encodings of DFP: DPD and BID.