Comments on P1788_Level2RoughDraft.pdf
Very nice! (As requested I did not read 6.7 and beyond.)
6.3.1 section on MidRad types. I often hear that the radius could be
expressed in a different format than the midpoint, e.g. with
less precision. This might be meaningful if it is RELATIVE,
but is problematic if it is absolute, unless the exponent
range for the midpoint format is artificially restricted to
match that of the radius format. On the other hand, relative
radius is problematical near a zero midpoint. So it seems
best to use a single format. (This problem goes away with
old formats like S/360 HFP, where the exponent range is the
same for all three supported precisions.)
My other concern is with the last sentence. I suppose it is
possible (at Level 3) to encode Empty, Entire and semi-unbounded
intervals, e.g. by using selected negative values for the radius.
Entire does have a natural representation with a positive infinite
radius (and meaningless midpoint). NaNs could also be used, but
it is dangerous to rely on NaN payloads. This *is* a Level 3
issue, which (given the overwhelming support for M0029.2) we are
supposed to leave alone except for interchange reasons, but I think
something needs to be said, if only that Level 3 is expected to
provide *some* encoding of, say, semibounded MidRad inntervals.
Actually, more has to be said, because the Mid() and Rad() functions
need to be defined! So perhaps we *should* standardize selected
negative Rad() values (without requiring that they actually be
stored as such in the representation, since that would be in
violation of M0029).
6.4.1 The "arbitrary set of reals s" as input to the hull(s) function is
a concept only, not an actual function argument. For example, it
is typically the range of a Level 1 function or operation. This
should perhaps be made clearer.
6.6.1 "Tightest" is unambiguous for any interval type only in its technical
sense of the T-hull requirements for "implicit" types.
Typo in definition of widen(x): missing right square bracket
Table 8: Please consult with Jean Michel Muller or his colleagues.
I was under the impression that exp/log were as difficult as
sin/cos, at least when sin/cos arguments are within reasonable
bounds. Perhaps the trig functions should be tightest within
an implementation-defined bound, and accurate otherwise. In
fact, the definition of "accurate" implies that the functions
could return [-1,+1] (or Entire for tan()) as soon as an input
ulp exceeds 2, which is well within the range where tightest
is not that difficult to achieve. So I would suggest that
the trig functions be defined to be tightest within a defined
bound that is larger than ulp=2, and with a defined and fixed
result interval outside that range.
The trigpi functions avoid this issue entirely, of course, which
suggests to me that they should be mandatory (and tightest).
There is also an issue with tan() in "accurate" mode even for
regular-size arguments: when input widening crosses pi/2 the
result could be Entire, whereas Tightest would return large
but finite endpoints of the same sign.
Michel.
---Sent: 2012-01-04 20:50:49 UTC