Motion 54 -- Level 2, Clauses 12.1-12.9
(I just realised that this discussion was supposed to end Nov 19;
unfortunately I had to wait until the weekend before I could do a
detailed reading of the material (P1788/D8.1 of Nov 15) -- and the
same goes for the sibling Motions 55-57.)
12.1.3, Exception behaviour:
"... a Level 2 operation always returns a value".
Is this not a bit too strong? Are we ruling out implementations
with unconditional exceptions that simply terminate the program?
One way of looking at this is by applying the "observability" rule.
If a program is terminated, it cannot observe the fact that the last
operation did not return, so the point is moot.
"...exceptions that may be signaled, causing a handler to be invoked."
Somewhere we should say that the standard will not say much about
how exceptions are handled, though perhaps an appendix can list some
possibilities. The issues are whether the handler can return in-line
with a substitute result, or whether it terminates some program unit
like a C longjump, or perhaps terminates the program entirely. Also
relevant is what information the handler may get: operation name and
arguments, or perhaps a representation of the result in a different
type that can express what the intended result type cannot. Such an
exceptional-result type need not be a computational type; it could for
example be something that describes which bound overflowed, or even by
how much (754 has used wrapped exponents, scale factors, or wider types
for this, for example).
Missing (though perhaps still under discussion): ContainmentFailure,
for flavors that only have a partial hull operation.
12.4, paragraph following the set of F-rules, typo:
"possible +-0" -> "possibly +-0"
12.5.1, near top of page 48:
"Two types are comparable if either is wider than the other."
"either" -> "one"
(Don't imitate old Massachusetts railway law: if two trains should
meet at a crossing, each shall wait until the other has passed.")
Next paragraph, identification of NaI with (Empty, ill) is something
that may need attention -- throughout the document.
12.6.2, bottom of page 48, mixed-type operations. As Vincent pointed
out, the double-rounding problem addressed by 754-2008 is not an issue
for directed rounding, and hence may not be an issue for inf-sup types.
So I suggest adding:
For inf-sup types this requirement may be met by implicit widening
of inputs to a common widest format, as double rounding is not an
issue for directed rounding.
Michel.
---Sent: 2013-11-25 02:14:58 UTC