Re: An error in Section 14.4 of the final draft
On Mon, 7 Jul 2014 09:45:46 +0100 John Pryce wrote:
> I suggest change "a generic NaN (no payload information)" to just "NaN",
> with no article.
Agreed.
> - On converting to the interchange bitstring, do we say the payload
> of such a NaN (at Level 4 it *has* a payload, one can't evade that)
> SHALL/SHOULD/MAY be preserved?
Definitely not. This kind of information is only relevant in a particular
implementation and has no place in an interchange format. I think it is
useful to know that imported intervals carry no extra baggage. This does
not prevent an implementation from recording whatever it wants in unused
(from a standard point of view) bits, but the standard need say nothing
beyond what it says in the Note.
> In view of the Note, I would support saying payload information SHALL be
> preserved "as far as possible" but am not sure how to say this simply,
> and in standardese.
Standardese for this is simply SHOULD -- but I'm still arguing against this.
It is true that the internal representation of a compressed decoration has
room for a vast number of bits beyond the three required to convey the bare
decoration, and an implementation may well record the CV of the datum in
those bits -- but that is beyond the standard. What is an importer to do
with extra bits? It would at a minimum have to figure out the source, and
applications are of course free to sign their exported data, but this is
beyond our purview, especially after we "dialled back" from trying to have
a standard signature.
The problem with trying to encode anything portably in a BFP NaN is that
there is simply no universal way to decode this. DFP is different; there
NaNs are fully specified, as are cohorts -- but DFP also has exploitable
redundancy in non-canonical encodings, and the arithmetic is carefully
designed to wipe this out so as to discourage this exploitation.
Michel.
---Sent: 2014-07-07 14:41:36 UTC