Re: ... replacement for 14.4 and C6.2 (interchange encodings)
Michel,
> all occurrences of "octets-encoding" (there are several) should be
> replaced with "octet-encoding".
Done in -r378 .
> Also, in the paragraph "Applications exchanging data...", line 5:
> merely requires the parameters -> merely requires that the parameters
The full text says
The standard merely requires the parameters of the octets-encoding
be communicated
Is this a bug or a differnce between Britain English and American English ?
Is it necessary to cahnge the form of "be" in your wording ?
You wrote
> there are
> several possibilities for encoding decorations, perhaps as NaN payloads,
> or as small FP integers in one bound with a generic NaN in the other (to
> avoid the many portability issues with NaN payloads).
What are the portability issues ?
It seems to me that program will get an exception with signalled NaNs and
then explore encodings as bit string to extract decoration values.
-Dima
----- Original Message -----
From: mhack@xxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Thursday, June 26, 2014 10:17:17 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: ... replacement for 14.4 and C6.2 (interchange encodings)
On Thu, 26 Jun 2014 05:40:37 -0700 (PDT) Dima wrote:
> Revision -r376 contains
> - Corresponding changes in C6.2.
> - §4.2 Definitions entries for "octet" & "octets-encoding".
> - Hyphen in beg-endian and little-endian (according to Wikipedia).
> **File: octets3.pdf
This looks good. As John Pryce pointed out, and Dima agreed, all
occurrences of "octets-encoding" (there are several) should be
replaced with "octet-encoding".
Also, in the paragraph "Applications exchanging data...", line 5:
merely requires the parameters -> merely requires that the parameters
I note that 14.4 now explicitly recognizes interchange representations
for both bare and decorated intervals, which is good.
I still think we need to say something about compressed intervals, if
they are supported (they are optional). That's because these would
need different encodings of the decoration, and here is where my
suggestion that decoration encodings be interpreted as small integers
instead of as bit strings has a definite advantage. We could show the
decorations both as a small integer and as an 8-bit octet. Another
possibility (so as not to rewrite the fourth paragraph of 14.4 a few
more times) is to mention the small-integer equivalence in the following
paragraph, which could be inserted after the Note and before the paragraph
that starts with "Export and import...":
When (optional) compressed intervals are supported, their interchange
representation is as described above for bare intervals for non-empty
intervals, but decorations are represented as a pair of floating-point
datums, the first of which is a generic NaN (no payload information),
and the second is a floating-point integer that encodes the decoration
as follows:
ill 0.0
emp 2.0
trv 4.0
def 8.0
dac 12.0
(Note that these encodings match the octet-encoded decorations
of decorated intervals, when interpreted as small integers, with
a new decoration *emp* to represent a compressed Empty interval.
The *com* decoration cannot occur in a compressed interval.)
Michel.
---Sent: 2014-06-26 18:16:46 UTC