Ian's comments on P1788-MAIN 6.3 (*not* M0014)
Ian McIntosh wrote:
> 1. The empty set representation was defined.:
> It's necessary for a receiver can know when a set is empty.
It's only necessary for the *interchange* format. Programs would use
the isEmpty() operation to determine the case.
> 3. The requirement that 0 be represented as +0 be removed.
Again, this does not affect internal representations. Whether
it is important to have a canonical representation of zero for
interchange formats is worthy of discussion. In my opinion it
is not essential (unlike the situation for encoding Empty), but
it might be useful because it would permit bit-level equality
testing at the interchange level.
This includes the case of the many many decimal zeros -- as well
as the choice of a canonical cohort (above and beyond canonical
representation thereof*). A logical canonical cohort would be
the one with the smallest exponent (i.e. normalized), though that
may feel unnatural for integral bounds. It would however lead to
a zero that looks like a zero (all bits zero), which is good.
Michel.
(*) IEEE 754-2008 requires that computational operations produce
canonical results, but appears to be silent on whether it is
conforming to export non-canonical interchange representations.
Since all operations must accept non-canonical representations
on input, my guess is that non-canonical forms ARE permitted.
P1788 might want to be more strict -- but would we want to pay
the cost of verifying canonicity? And if we don't enforce the
constraint, should there be one? Note that the only way for a
non-canonical output to appear is if it is a non-canonical input
that was propagated without ever participating in arithmetic, or
even min/max filtering.
---Sent: 2010-05-31 17:53:17 UTC