[Cfp-interest] TS Parts 2
Fred J. Tydeman
tydeman at tybor.com
Tue Jul 17 14:00:44 PDT 2012
On Mon, 18 Jun 2012 20:19:31 -0700 Jim Thomas wrote:
>
>I've post updates for Part 1 and Part 2 of our draft TS on the CFP wiki.
My comments for Thursday teleconference:
It might help if all paragraphs were numbered (so that comments can
specify what is being commented upon).
0.1 Background
PDF page 5, 1st paragraph: "binary to-and-from decimal conversion" ->
"conversion between binary and decimal".
4th paragraph: Add "REXX" before "C#".
0.4 The formats
PDF page 6, 4th paragraph: 1999 -> 1989.
Also, consider changing 60559 to [60]559.
2.0 Conformance
PDF page 7, 4th paragraph: Types are in the compiler, not in headers ???
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".
PDF page 9, 9th paragraph: Make the footnote reference "1)" be a
superscript.
Seems we are missing (between 6.2.5 and 6.7.2):
Add to 6.4.1 Keywords
Syntax
_Decimal32
_Decimal64
_Decimal128
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.
Seems we need more for 6.7.2:
Add to the Constraints list:
_Decimal32
_Decimal64
_Decimal128
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.
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, should the 3 _DecimalNN be here?
7.0 Characteristics of decimal floating types <float.h>
PDF page 10, 3rd paragraph: Add "first" before "included".
12th paragraph: Why the "(and IEC 60559)" in "For binary
floating-point following IEC 60559 (and IEC 60559),"?
PDF page 11-12: ISSUE: Change "_SUBNORMAL_" to "_TRUE_" (to match C11
style).
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?
PDF page 12, last paragraph: Remove "is in the range of values that
can be represented but". 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".
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."?
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.
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.
10.2 Functions
PDF page 16: Add "islessgreater" after "islessequal".
10.3 Conversions
PDF page 17: "different formats" -> "different floating formats"
11.1 Standard headers
PDF page 17: "appropriate header is included" -> "appropriate header
is first included".
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.
Do we need words along the lines of C11 Annex F.8.2 Translation?
Add: The macros expand to integer constant expressions whose values
are distinct nonnegative values.
11.3 Decimal mathematics <math.h>
PDF page 19
Need to add "ISSUE" near where you have "(???)".
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".
PDF page 21: Footnotes 2 and 3 need to be superscripts.
PDF page 24: Footnote 4 needs to be superscript.
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.
Also, does "normalized fraction" have any meaning for DPF and cohorts?
What cohort is produced for subnormal operands?
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."
11.4 New <math.h> functions
PDF page 27: For quantize, would be better to say "quantum exponent"
in place of "exponent"?
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.
In [3], should 'true' and 'false' be bold?
11.5 Formatted input/output specifiers
PDF page 29: What happens for a precision modifier of zero? Treat as
one?
On PDF page 30, add to examples:
printf("%.0Ha\n", x);
with result of(?):
7e+3
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.
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.
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).
PDF page 32, Returns[10]: Why ERANGE instead of raising overflow or
underflow? Why +0.E0dd instead of raising invalid and return a NaN
for bad input? 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,"
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?
If yes, with what name?
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?
Should C11 6.11.1 Floating types be updated to mention _Decimal128?
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?
Are we going to do _Atomic versions of DFP types?
Are we going to have functions to convert between the two encodings of
DFP: DPD and BID?
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.
---
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.
More information about the Cfp-interest
mailing list