Motion 51: YES, with comments
I vote YES on M0051 (clause 12.11, 2013-10-24 version).
But I have some minor comments, and a more important one but to be
dealt with in a later motion.
§12.11.1, 4th paragraph: I dislike the "is not mandatory at Level 1"
as even optional features should be in their own chapters/sections.
All the numbers and intervals considered here are Level 1 numbers and
intervals. I'm wondering what actually belongs to Level 2 here. Finite
strings? I think so, because all strings considered here belong to
some "string" data type or something equivalent (in C, a string is
a sequence of characters terminated by a null character): indeed, in
most languages, strings are unbounded -- bounded in practice only by
environmental limitations. But these strings could also be regarded
as Level 1 datums: as strings, they are not approximations. So, IMHO,
§12.11 may be moved to the Level 1 section. Or this paragraph could
be reworded.
§12.11.2, item (b): "A number in the hexadecimal-floating-constant
form of the C99 standard" is incorrect as this form doesn't include
numbers starting with a sign (in particular, negative numbers): in C,
a "-" or "+" before a number constant is always an operator.
After this list: "It may restrict the support of literals, by relaxing
conversion accuracy of hard cases: rational literals, long strings,
etc., converting such literals to Entire, for example." should be
rewritten because it belongs to "12.11.2. Number literals." and Entire
isn't a number. It could also be removed, as IMHO, a restriction text
in §12.11.6 is sufficient (since number literals occur only as part of
interval literals).
Next paragraph: I wonder what "By default" means here. Remove it?
And I agree with Michel Hack to prefix "e.g." to "C locale" (because
"C locale" is specific to the C language and related environments.
§12.11.3: remove the comma after "x ulps" (or add a comma after
"x ulps of s").
§12.11.4, item (b): "A string [ x ] is equivalent to [ x , x ]."
To make sure that there is no ambiguity, I would add "where x is a
number literal representing a finite number". So, [entire,entire]
is not a portable interval literal, and [inf] and [inf,inf] are not
regarded as equivalent (just in case an implementation would support
one of these forms with a special meaning, possibly in a specific
flavor). This is more detailed that Michel Hack's suggestion.
§12.11.6: "[...] of any implementation *shall* accept *any* portable
interval. Implementation may restrict support of some input strings
[...]" is contradictory. Replace "shall" by "should"?
Something important related to this restriction (but I think this
should be part in a separate motion on exceptions): in case of string
restriction, an exception is probably needed, in particular when the
input may be of the form [l,u] with l > u but the implementation is
not able to decide.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)