Re: A general comment Re: Proposed replacement for 14.4 and C6.2 (interchange encodings)
Michel,
I guess that you are discussing now the "Proposed replacement for 14.4 and C6.2 (interchange encodings)"
with some group mebers.
May I request you to copy your discussion or its digest to the mailing-list ?
Some previous discussions about interchange representation were held privately,
and we see now that it was wrong.
Particulary, I'm curious about your decision about the following topics.
1) Where will be a place to define mapping to octets ?
A) It is level 5.
Level 3 is a pair or tripple of Level 2 floating-point datum and an abstract decoration;
Level 4 is a bit string;
Level 5 is a sequence of octets.
B) It is level 4.
Level 3 is a pair or tripple of Level 2 floating-point datum and an abstract decoration;
Level 4 is a sequence of octets.
2) What is a name for a sequence of octets ?
Level 3 is called representation;
Level A.4 is called encoding;
Whare is the name of A.5 or B.4 ?
I think that "mapping" is too general word.
3) Is A.5/B.4 required, recommended or annex ?
4) Is signature an ascii string or an octet sequence or a structure of C language ?
5) Do we try to define representation, encoding and mapping for compressed intervals ?
-Dima
----- Original Message -----
From: rbk5287@xxxxxxxxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Monday, June 23, 2014 8:15:29 PM GMT +04:00 Abu Dhabi / Muscat
Subject: A general comment Re: Proposed replacement for 14.4 and C6.2 (interchange encodings)
Michel, Vincent,
I'm glad we are converging quickly towards a resolution of this
problem, so the P-1788 membership will have as much
time as possible to review the final document (somewhat
polished during our ongoing vote) before the upcoming July 8
MSC meeting.
Baker
On 06/23/2014 10:05 AM, Vincent Lefevre wrote:
> On 2014-06-23 09:41:21 -0400, Michel Hack wrote:
>> I had started to think in terms of a plain character string, but here
>> are several reasons why I changed to the mixed text/binary format:
>>
>> (0) In the above, 'p1788' is inappropriate; the 'p' (for Project) will
>> go away if and when this actually becomes an IEEE standard.
>
> Yes, with "ieee", this is better. But some people might prefer the
> reverse domain name notation:
>
> https://en.wikipedia.org/wiki/Reverse_domain_name_notation
>
> e.g. a name starting with "org.ieee."
>
>> (1) I would have had to invent short names for the byte ordering.
>> Dima's "MSB" is incomplete, it should be "MSBF" for "Most
>> Significant Byte First", but may be better than "BE" or "LE".
>
> I think that "BE" and "LE" are commonly used, e.g. by
>
> http://tools.ietf.org/html/rfc2781
>
> for some charsets.
>
> IMHO, only lower case characters (as opposed to upper case) should be
> used in the name.
>
>> (2) I wanted a fixed-length signature, preferably a multiple of 4 bytes.
>> That fits more easily into structure layouts in many languages.
>>
>> (3) I want to accomodate ALL 754-2008 formats, including the extendable
>> ones that can have arbitrary size (in multiples of 32 bits). Such
>> sizes are better represented in binary than in a decimal character
>> string.
>
> Of course, not completely arbitrary sizes. But... yesterday, and this
> is recalled in your next point, you said:
>
> "assuming that the size is less than 2**24, which is presumably
> large enough to cover any extended format being contemplated in
> the near future"
>
> I'm not so sure. What I know is that some people work with much larger
> precisions. I don't know whether they are interested in regarding such
> numbers as numbers of some 754-2008 extendable format, though.
>
> Also, make sure that the signature format is OK for the next 30 years
> (when considering standards, 30 years is the the near future).
>
> For this reason, a 32-bit size field may not be enough. I would go for
> a 64-bit one.
>
>> (4) The method of detecting Endianness by looking at a binary field of
>> known content is quite general. If in fact the application already
>> knows the size (which is likely), this could even detect some messy
>> mixed-endian formats, although there are values where all four bytes
>> would be the same and hence useless as an indicator. (That's why I
>> mentioned 2**24 as a practical upper limit.)
>
> I think that detecting endianness should be done in a clean way.
>
--
---------------------------------------------------------------
Ralph Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------