Re: Motion P1788/M0029.01: Level-3-interface-only --- discussion period begins
Lee Winter wrote:
"Finally, if the standard mandates a compressed representation then
that representation will of necessity be found in floating-point data
layouts. Any external representation that faithfully represents the
data layout will carry along the compressed format -- no extra
interpretations would be necessary. SEM is one such external
representation.... It is possible that I lack comprehension of the issue you
are pointing out."
Then let me back-up a little, to be sure we first have a common
understanding...
Although I really like the moniker "compressed intervals" (I think John came
up with this), I agree it can be a little misleading. For example, a
compressed interval doesn't really mean an [xlo,xhi] representation packed
into fewer bits. Instead, it is supposed to be a datatype that in a
mutally-exclusive manner represents one of the following:
(a) an element of overline-IR, i.e., a closed (possibly unbounded)
interval or the Empty set; or
(b) NaI (Not-An-Interval) as described in Motion 8, i.e., one of the
bare decorations (such as ein, dac, def, gap, ndf, etc.) from one of the
various decoration schemes that are being proposed.
The (a) and (b) above are supposed to be roughly analagous to how in IEEE
754 SEM a datum is either i) numeric or ii) NaN... but the datum is never
numeric and NaN at the same time.
The main distinction between NaN and NaI is that:
-- NaI comes in many "flavors" (ein, dac, def, gap, ndf, etc.), and
-- NaI must propagate through interval operations according to
standardized rules that are yet to be specified by P1788.
For example, an interval addition operation on two NaI datums:
dac + def
must propagate the def NaI over the dac NaI.
"Are you aware of and/or can you describe a case in which the SEM encoding
is not adequate to represent compressed intervals?"
Strictly speaking I think we could *represent* compressed intervals with
SEM by using the extra NaN payload bits to indicate the various flavors of
NaI. They problem, as I understand it, is as follows:
IEEE 754 NaNs, I've been told, don't have any standard rules for how the
payload bits in the NaN propagate through floating-point operations. So if
we use the NaN payload bits to try and distinguish the various flavors of
NaI, we won't be able to rely on that information getting propagated through
the underlying floating-point operations in any consistent manner. For
example, it will be really difficult to ensure in the example above that the
def NaI propagates through the addition operation over the dac NaI.
So possibly SEM is good enough for purely exchanging data between P1788
implementations. But this may make it real difficult to ensure the NaI
information is then propagated correctly by using existing IEEE 754 hardware
once an actual computation is commenced.
Does any of this help shed light on the issue?
Nate