Baker Kearfott wrote:
Well, we've talked about the "good" and the "bad." Now, how about
the "ugly." I may be run out of town by some 754'ers for bringing
this up, but, speaking of many different allowable formats, we could
conceivably allow separate formats for mid-rad and inf-sup.
then compared this to the two permitted interchange encodings
for DFP in IEEE 754-2008 (Intel's BID and IBM's DPD).
That comparison is invalid, because, sad as it may be that
we could not agree on ONE interchange format for DFP, the two
encodings represent *exactly* the same set of floating-point
numbers, including NaNs. IEEE 754-2008 also requires that
there be conversions between the native format and the other
one, which are EXACT in all cases; no exceptions. The result
of such a conversion will be canonical (each format has some
redundant bit patterns, but each class of redundant forms has
exactly one well-defined canonical member).
If both infsup and midrad forms were to be primary interval types
they would have to be *different* types, since the value-sets are
distinct.
It is pretty clear that midrad is sufficiently useful that some
support should be included. That could be as a secondary type,
possibly without an interchange format, and with a different set
of operations appropriate for the application domain.
This seems a good place to remind everybody of a point I have made
in the past: there are two conceptually different interpretations of
intervals: as ranges of possible values (where infsup is definitely
superior), and as imprecise single values (where midrad seems preferred).
We need to come to grips with that distinction, because it affects our
expectations for how various operations are to be defined.
The discussions of three-element pseudo-midrad forms were an attempt to
find common ground, and to satisfy the exact-convertibility requirement
of Motion 14. I'm afraid they failed to reach that goal.
Michel.
---Sent: 2010-05-07 17:33:52 UTC