Without the rationale, the motion text would be completely
unintelligible to me too. Perhaps someboy will offer a
friendly amendment to rephrase it -- somebody who knows what
it means, as opposed to those of us who are still guessing.
The mention of the Vienna Proposal suggests that the intent is to
specify the properties that *intervals* must have, regardless of
how those are supported by the underlying FP arithmetic. It then
points out how Inf and NaN representations of 754 can be used by
an implementation -- and even suggests a non-754 way to redefine
directed rounding to be IA-friendly. So a 754 variant that was
IA-friendly would be non-754-compliant!
FP formats that don't include Inf and NaN (like the old IBM HFP)
need not present a problem: the implementation can reserve some
of the extreme values to stand for Inf and NaN, at the cost of
extra checks of course. It could also use a storage format that
has room for extra status bits. (I'm not proposing that this ever
be considered -- HFP is obsolete in the sense that any machine less
than 10 years old that supports HFP also supports BFP (IEEE 754) --
although compilers for Z may still default to HFP code generation.)
In other words, 1788 need not worry about the presence of NaNs, it
can delegate that worry to implementations. (It does however have
to make up its mind about Empty, NaI, or both.)
Michel.
---Sent: 2009-04-09 21:41:16 UTC