[Cfp-interest] TS Parts 2

[Jim Thomas]

At our July teleconference we discussed Fred's comments of July 17, 2012 on the TS Part 2 draft. The following shows Fred's comments followed by responses from our July teleconference ( and some from me) and our resolutions in capital letters (typically DONE, NO CHANGE, or REVISIT). For the items beyond what we covered in the teleconference the responses are mine.

Please review prior to the meeting and report any errors in the resolutions. Also give the rest of Fred's comments careful attention (he's identified some interesting issues). Email discussion prior to the meeting is encouraged.

-Jim

On Jul 17, 2012, at 2:00 PM, Fred J. Tydeman wrote:

> It might help if all paragraphs were numbered (so that comments can
> specify what is being commented upon).

look into adding paragraph numbers
don't see a reasonable way to do it
REVISIT

> 
> 0.1 Background
> 
> PDF page 5, 1st paragraph: "binary to-and-from decimal conversion" ->
> "conversion between binary and decimal".

yes - DONE

> 
> 4th paragraph:  Add "REXX" before "C#".

No objection - DONE

> 
> 0.4 The formats
> 
> PDF page 6, 4th paragraph:  1999 -> 1989.

ok - DONE

>  
> Also, consider changing 60559 to [60]559.

NO CHANGE

> 
> 2.0 Conformance
> 
> PDF page 7, 4th paragraph:  Types are in the compiler, not in headers ???

right. _DecimalN_t types are missing
ok as is - NO CHANGE

> 
> 6.0 Decimal floating types
> 
> PDF page 8, 2nd paragraph: What is a "base type"?  That term is not in
> C11.  However, there is "basic type".

should be basic - DONE

> 
> PDF page 9, 9th paragraph: Make the footnote reference "1)" be a
> superscript.

fixed
fix the rest - DONE

> 
> Seems we are missing (between 6.2.5 and 6.7.2):
>  Add to 6.4.1 Keywords
>   Syntax
>    _Decimal32
>    _Decimal64
>    _Decimal128

TR FIX

>   Semantics
>    The keywords _Decimal32, _Decimal64, _Decimal128 are reserved for
> specifying decimal floating types and are keywords if and only if both
> __STDC_DEC_FP__ and __STDC_WANT_DEC_FP__ are defined.

WANT macro is only for library - NO CHANGE

> 
> Seems we need more for 6.7.2:
>  Add to the Constraints list:
>    _Decimal32
>    _Decimal64
>    _Decimal128

yes, TR FIX

> 
> And perhaps a new paragraph after #3:
> The type specifiers
>    _Decimal32
>    _Decimal64
>    _Decimal128
> shall not be used if the implementation does not provide those types.

same as with any other conditional feature - NO CHANGE

> 
> A bigger issue: Since _Imaginary is not in the list of type
> specifiers, and
>  _Imaginary float
>  _Imaginary double
>  _Imaginary long double
> are not in the list in Constraints,

Does G.2 [1] suffice? - out of scope for CFP? - REVISIT

> should the 3 _DecimalNN be here?

TR fix? - REVISIt

> 
> 
> 7.0 Characteristics of decimal floating types <float.h>
> 
> PDF page 10, 3rd paragraph:  Add "first" before "included".

yes - DONE

> 
> 12th paragraph: Why the "(and IEC 60559)" in "For binary
> floating-point following IEC 60559 (and IEC 60559),"?

one was probably 754 - DONE

> 
> PDF page 11-12: ISSUE: Change "_SUBNORMAL_" to "_TRUE_" (to match C11
> style).

maybe
TR fix? - REVISIT

> 
> 8.1 Conversions between decimal floating and integer
> 
> PDF page 12: Does conversion from FP to int raise inexact?
> Unspecified?  Like C11 Annex F.4?

should be like c11 + part 1, which is unspecified
already covered in F.4
we don't capture 754 recommendation for implicit inexact conversion to signal
REVISIT

> 
> PDF page 12, last paragraph: Remove "is in the range of values that
> can be represented but".  

seems right - REVISIT

> Reason: Since -infinity and +infinity are
> part of DFP, all values are in the range that can be represented.
> Or, perhaps, we need to add finite range, or normalized range.
> 
> 8.2 Conversions among decimal floating types, and between decimal
> floating types and generic floating types
> 
> PDF page 12, last paragraph: Remove "is in the range of values that
> can be represented but".

do we assume conformance to part 1? seems not - is this ok?
without part 1 (or annex F conformance) we don't know generic floating types have infinities - so need to retain words or equivalent - REVISIT

> 
> 9.0 Constants
> 
> PDF page 14, paragraph about 6.4.4.2#5: Do we need to add: "Decimal
> floating-point constants shall be correctly rounded."?

if not already covered - we might want to adapt, or refer to, the operation binding table in Part 1, e.g.,
The binding of 60559 operations to C decimal operation is analogous to the binding in Part 1 for binary operations, with these exceptions: …
REVISIT

> 
> 9.1.1 The FLOAT_CONST_DECIMAL64 pragma
> 
> PDF page 15, 3rd paragraph: ISSUE: This pragma, introduced in TR
> 24732:2008, is deprecated in this Technical Specification.
> 
> Last paragraph in this section: ISSUE: [2] Use of the
> FLOAT_CONST_DECIMAL64 pragma is an obsolescent feature.
> 
> If we add this change from the original TR, then we should add the
> issues I have identified.  Also, this should be identified as an
> issue.

don't understand issues
REVISIT

> 
> 10.1 Operators
> 
> PDF page 15, only paragraph in section 10.1
> Do we have words to this effect as a suggested change to C11?
> I guess that the change to 6.5#8 does that.

is there still an issue here?
REVISIT

> 
> 10.2 Functions
> PDF page 16:  Add "islessgreater" after "islessequal".

yes - DONE

> 
> 10.3 Conversions
> PDF page 17:  "different formats" -> "different floating formats"

yes - DONE
change "formats" to "types" - DONE

> 
> 11.1 Standard headers
> PDF page 17: "appropriate header is included" -> "appropriate header
> is first included".

yes - DONE

> 
> 11.2 Floating-point environment <fenv.h>
> PDF page 18 for C11 7.6#8:
> Add "(both translation time and runtime)" to: The default rounding
> direction for decimal floating-point operations shall be
> FE_DEC_TONEAREST.

ok - see resolution of next item
REVISIT

> 
> Do we need words along the lines of C11 Annex F.8.2 Translation?

maybe? - DONE - REVIEW

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

yes - DONE

> 
> 11.3 Decimal mathematics <math.h>
> PDF page 19
> Need to add "ISSUE" near where you have "(???)".

should be 7.12.14 - DONE

> 
> PDF page 20, paragraph 8: Change "macro" to "macros" in:
> "Add at the end of 7.12 paragraph 7 the following macro."
> and change "[7] The macro" to "[7] The macros".

yes - DONE

> 
> PDF page 21:  Footnotes 2 and 3 need to be superscripts.

fixed - DONE

> 
> PDF page 24:  Footnote 4 needs to be superscript.

yes - DONE


--------- got to here at July teleconf ----------

> 
> PDF page 26, frexp: Change "If value is a decimal floating- point
> number, the exponent is an integral power of 10; otherwise it is an
> integral power of 2." to "If value is a generic floating-point value,
> the exponent is integral power of 2, otherwise if is an integral
> power of 10".  Reason: If generic FP types are decimal, it is
> confusing to know if 'float' is a decimal floating-point number.
> The issue applies to logb and scalbn on the next page.

seems right?
how is frexp implemented if RADIX is 10? is x converted to binary to get the exponent, then the normalized binary fraction converted back to decimal?
are there any implementations with RADIX 10?

> 
> Also, does "normalized fraction" have any meaning for DPF and cohorts?

yes - a normalized fraction will be a cohort member with minimum quantum exponent:

> What cohort is produced for subnormal operands?

CFP spec for quantum exponents says:

[10] With the assumption that frexp should produce a result with the same coefficient digits as its value argument, we get

frexp -- Q(frexp(value, exp)) = Q(value) if value = 0 and
= -(length of coefficient of value) otherwise


> 
> PDF page 26, ldexp: Change "A range error may occur." to "A range
> error may occur for finite arguments."
> 
> PDF page 27, scalbn: Change "A range error may occur." to "A range
> error may occur for finite arguments."

What happened with these in WG14?

> 
> 11.4 New <math.h> functions
> 
> PDF page 27: For quantize, would be better to say "quantum exponent"
> in place of "exponent"?

Yes. Check other places too.

> 
> PDF page 28: To make the samequantum function useful in C++, "_Bool"
> should be replaced with "bool" and #include <stdbool.h> added to the
> synopsis.

C11 uses _Bool

> 
> In [3], should 'true' and 'false' be bold?

C11 uses "nonzero (true)" for _Bool value

> 
> 11.5 Formatted input/output specifiers
> PDF page 29: What happens for a precision modifier of zero?  Treat as
> one?

Seems right

>  
> 
> On PDF page 30, add to examples:
>  printf("%.0Ha\n", x);
> with result of(?):
>  7e+3

Is this needed (assuming spec is made clear)?

> 
> What is the result of:
>  printf("%.1Ha\n", DEC32_MAX);
> Is it INFINITY or 1e97?  I believe it is INFINITY. 
> As if round source value.

Yes, (0, 9999999, 90) -> inf

What if rounding down? what does "rounds the input, in the type, according to the current rounding direction for decimal floating-point operations, to the number of digits specified by the precision modifier" really mean?

(0, 1234567, 0) -> (1000000, 0) or (0, 1, 6)? Check implementations. Former has same quantum exponent as input.

For the max case the latter isn't an option because it's at the limit of the exponent range:
 (0, 9999999, 90) -> (0, 9000000, 90) -> 9.000000e96

Designed to reflect the quantum exponent?

> 
> This is the opposite behaviour of:
>  printf("%.1a\n", DBL_MAX);
> Is it INFINITY or 0x2p1023?  I believe it is 0x2p1023.
> As if round destination value.

Yes, aA conversion for binary is different. Because it doesn't need to preserve quantum exponents?

> 
> 11.6 strtod32, strtod64, and strtod128 functions <stdlib.h>
> PDF page 31, item [4]:
> Add at the end of: 
>  "If the subject sequence begins with a minus sign, the sequence is
>   interpreted as negated."
> (before rounding).

It says the sequence is interpreted as negated, not that the result of rounding the unnegated sequence is negated. So no change needed

> 
> PDF page 32, Returns[10]: Why ERANGE instead of raising overflow or
> underflow?  

This is in the main body of the standard, so follows the language there. They do have to raise overflow and underflow because they are 60559 operations (except for next item)

> Why +0.E0dd instead of raising invalid and return a NaN
> for bad input?  

HIstorical behavior of strtod.

> These are new functions, so need not be constrained by
> existing C89 behaviour on non-IEEE-754 platforms.
> 
> Change "If the correct value is outside the range of representable
> values," to "If the correct value is outside the range of finite
> representable values,"

seems ok

> 
> 11.7 wcstod32, wcstod64, and wcstod128 functions <wchar.h>
> Same comments as for strtod32...
> 
> 11.8 Type-generic macros <tgmath.h>
> The informal description needs work as well as we need words for C11 7.25.
> Are quantize, samequantum, and quantexp supposed to be type generic?

yes

>  
> If yes, with what name?

unsuffixed

> Need to cover three cases:
>  remquo() with decimal FP types or with integer types -- need words
>  quantize() with binary FP types or with integer types  -- need words
>  fma() with decimal, binary, or mixed types -- existing words.
> 
> Should the cbrt example in C11 6.5.1.1 Generic selection be updated
> with DFP types?

look into

> 
> Should C11 6.11.1 Floating types be updated to mention _Decimal128?

one of many possible future language directions from the TS

> 
> Should A.1.2 Keywords be updated?  
> 
> Should A.2.2 Declarations (6.7.2) be updated?
> 
> Should B.5 Floating-point environment <fenv.h> be updated?
> 
> Should B.6 Characteristics of floating types <float.h> be updated?
> 
> Should B.11 Mathematics <math.h> be updated?
> 
> Should B.21 General utilities <stdlib.h> be updated?
> 
> Should B.24 Type-generic math <tgmath.h> be updated?
> 
> Should B.28 Extended multibyte/wide character utilities <wchar.h> be
> updated?
> 
> Should Annex E Implementation limits be updated?
> 
> Should Annex H Language independent arithmetic be updated?
> 
> Should Annex J.3.6 Floating Point be updated?
> Should Annex J.3.12 Library functions be updated?
> Should Annex J.5.6 Other arithmetic types be updated?

Do Technical Specifications typically include changes for the annexes above?
> 
> Are we going to do _Atomic versions of DFP types?

Isn't it automatic unless we add a constraint?

> 
> Are we going to have functions to convert between the two encodings of
> DFP: DPD and BID?

hope so - we have them in our internal CFP spec

> 
> Do we need something along the lines of F.9.2 Expression transformations 
> specific to DFP?
>  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.

probably so

> 
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 358-9748      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20120802/4f3a09b2/attachment-0001.html