Motion 31: V04.2 Revision of proposed Level 1 text
Some comments:
4.1 Specification levels overview. Mention openface-T in the text
for Level 2, so that T-hull does not come as a surprise in a.
I know that it is defined in the table; I was just wondering
whether that was sufficient.
5.5.2 Generic functions. "The implementation's library contains
all computable versions ...".
ALL computable versions? That seems like a LOT. Perhaps
"at least one", or some other qualification; in fact, the
set of realistic versions won't make sense until Level 2.
Perhaps "all computable versions required by Level 2"?
5.5.3 Point functions ... "... the undefined function NaN ..."
Cute -- given that constants are 0-ary functions, this is
in fact a perfectly well-defined constant!
5.6.1 Constants. I suppose 'expressible in the C language" is just a
placeholder at this point. This is separate from using C syntax in
an illustrative manner in the standard ("This standard writes..."),
which is ok.
Can we not simply tie this to the definition of expressions in 5.5.3,
using point functions from the set of required point point functions?
In other words, compile-time expressions (no variables, only functions,
including constants (i.e. literals)).
Table 2, Required forwards elementary functions, Note h: round() should imply
ties-away-from-zero? Really? Why not stick with the 754 default,
ties-to-even (at least for BFP; for DFP ties-to-even is recommended,
but subject to language definition).
Perhaps tie it to the language's rule for default rounding, avoiding
mention of 754, or just mention it as an example.
Table 3, Required reverse elementary functions. We need two versions of
the non-commutative ones: divRev1, divRev2, powRev1, powRev2 -- or
perhaps powRev2 is not needed or practical.
Table 4, Required numeric functions. midRad() is not a numeric function
according to 5.6.8 ("the result a number"). Indeed, at Level 2
there would be a problem: what kind of beast is "a pair of numbers"?
What could be said is that implementations are encouraged to provide
a way return both mid() and rad() of the same interval in a manner
that avoids extra work, just as quotient and remainder are often
delivered together. Many compilers will be able to deduce this
from context when the two nominally-separate functions are invoked
next to each other.
If an implicit midrad type is supported, it should of course have a
constructor, or type conversion from infsup to midrad, but that falls
under extra type-specific operations (something that can only happen
at Level 2).
Michel.
---Sent: 2012-01-26 23:42:58 UTC