Re: An error in Section 14.4 of the final draft
P1788
On 2014 Jul 5, at 22:36, Kreinovich, Vladik wrote:
> I agree too, if there will be objections to the standard in the general vote most likely they will be not about this...
I agree. Let's keep the text as is for now and note it needs attention.
But reading 14.4 with more care I agree the paragraph "When (optional) compressed..." needs improving. It is a matter of saying clearly what is, I hope, clear in our heads.
(1) "as described above for bare intervals for non-empty intervals, but decorations are represented as ..." is certainly hard to parse. I had to read it several times before I got it.
(2) IEEE754-2008 §3.2 is precise about the distinction between datum, representation and encoding (Levels 2,3 and 4). In this paragraph, Michel uses the word "datum" - 754 Level 2 which has only one NaN. BTW "generic NaN" is nowhere used in 754-2008.
I suggest change "a generic NaN (no payload information)" to just "NaN", with no article.
On 2014 Jul 5, at 17:15, Michel Hack wrote:
> But I wanted to stress that the interchange format explicitly avoids using the NaN payload to convey information ...
I.e. information about *the value of the compressed datum*. But the Note, just before this paragraph, says an implementation may store information in a payload for other purposes.
Since interchange is about two implementations communicating, there is a substantive (if minor) point here.
- For a compressed type T, the internal representation of a T-interval xx MIGHT use NaN(s) in case xx is a decoration; when T derives from a 754 inf-sup type this seems unavoidable.
- An implementation MIGHT store useful information in such a NaN.
- It MIGHT be useful when converting to interchange form, for sending to another platform, to preserve such information, which the receiver MIGHT use.
- 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?
There are complications, e.g. if decoration xx is stored internally as
NaN, NaN
where one of them encodes the decoration value. Then the interchange form
Nan, FP integer
can only store a single NaN payload, but a perverse implementation might store the decoration in 3 payload bits and use the rest of both payloads (2*52-3 = 101 bits in case of binary64) for "useful information".
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.
John Pryce
> ________________________________________
> From: stds-1788@xxxxxxxx [stds-1788@xxxxxxxx] on behalf of Michel Hack [mhack@xxxxxxx]
> Sent: Saturday, July 05, 2014 10:15 AM
> To: stds-1788
> Subject: Re: An error in Section 14.4 of the final draft
>
> In any case, these stylistic fixes are not urgent -- we should keep track
> of them and deal with them at a later stage. I don't think we need to hold
> up presenting what we have to the MSC. Baker, George, John, Christian?
>
> (Of course, if the next three days bring a flood of reversed votes...)
>
> Michel.