Re: Proposed replacement for 14.4 and C6.2 (interchange encodings)
Michel,
One more variant of resolving the interchange encoding issue:
1) leave 4 encoding to be bit string encoding as it is defined now;
2) change encoding of decorations according to your suggestion:
ill 00000000
trv 00000100
def 00001000
dac 00001100
com 00010000
3) Add at the end of 14.4
<<<
The length of interchange encoding bit string is a multiple of 8 because
interchange media (files, network) is usually organized in bytes/octets.
The mapping from a level 4 bit string to bytes/octets is not defined by this
standard. See see appendix XXX for examples of this mapping.
>>>
4) Add appendix XXX. This appendix will contain two mappings.
i) Your description of signature and mapping ;
signature specifies both parameters of encoding and of mapping
bin/bid/dpd - parameter of encoding
length of floating point datum - parameter of encoding
order of octets inside floating point - parameter of mapping
number of zero octets before/after decoration octet - parameter of mapping
ii) The plain mapping splits the level 4 bitstring into octets from left to right.
> We can add "Endianness" to the glossary in Chapter 2:
Instead the appendix can describe mapping from bit string to octets explicitly without using the word "Endianess".
> By the way, bit numbering is ALSO suspect without further information!
I agree.
In the previous emails I implicitly assumed that
the index of leftmost bit is 63 and the index of rightmost bit is 0.
I was wrong. The length of representation is 2*64+8=136 bits.
The index of leftmost bit is 0, the index of rightmost bit os 135.
> The signature is NOT A HEADER! It can be a component of a header, and
What do you think about defining the signature as an ANSI string ?
It could explicitly specify:
- order of octets ( lsb/msb ),
- number of bits in floating-point format,
- number of bits in decoration together with padding zero octets.
For example
p1788_bin64_msb_d8 - the plain format for decorated infsup_bin64
p1788_bin64_lsb_d32 - useful on x86 machines format for decorated infsup_bin64
p1788_bid32_msb_d8 - one of the plain formats for decorated infsup_dec32
p1788_dpd32_msb_d8 - another plain format for decorated infsup_dec32
p1788_bin64_msb - the plain format for bare infsup_bin64
The mapping from bits to octets for p1788_binN_msb_dM is
bits[i*8:i*8+7] for i in [0,N/8-1]
bits[N+i*8:N+i*8+7] for i in [0,N/8-1]
00000000 M/8-1 times
bits[N*2:N*2+7]
The mapping from bits to octets for p1788_binN_lsb_dM is
bits[N-i*8-8:N-i*8-1] for i in [0,N/8-1]
bits[N*2-i*8-8:N*2-i*8-1] for i in [0,N/8-1]
bits[N*2:N*2+7]
00000000 M/8-1 times.
The mapping from bits to octets for P1788_binN_msb_d8 could be written simpler
bits[i*8:i*8+7] for i in [0,N/4].
-Dima
----- Original Message -----
From: mhack@xxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Monday, June 23, 2014 2:08:04 AM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: Proposed replacement for 14.4 and C6.2 (interchange encodings)
Dima (Dmitry Nadezhin) replied to my post:
> 1) This text uses the word Endianess, but without definition.
> We might imagine four mappings of binary64 bits into a sequence of bytes:
We can add "Endianness" to the glossary in Chapter 2:
Endianness denotes one of two common byte orders for common multibyte
objects such as integers or IEEE 754-2008 formats, called Big-Endian
and Little-Endian. (There used to be a greater variety of byte orders,
but for 754 formats the world appears to have settled on just two.)
So I think we can avoid the complication of other permutations. By the
way, bit numbering is ALSO suspect without further information!
> 2) There are still other useful encodings that are not defined by
> this header. For example, it is possible to write vector of
> length L of infsup_b64 decorated intervals.
The signature is NOT A HEADER! It can be a component of a header, and
it is thus useful for it to have a standard representation from which
relevant platform-dependent parameters can be derived. Applications
typically need to know much more about the structure of imported data,
but that knowledge is APPLICATION-specific. The intent of the signature
is simply to capture PLATFORM dependencies.
> 3) There may be a lot of header defined encodings,
See above.
I also realised that whether an application exports decorated or bare
intervals is also an application property, and therefore need not be
encoded in the signature. What we can add to my description is that
the same signature can also be used to describe bare intervals, which
can indeed be useful in bulk interchange.
This also gives an application the opportunity to export an array of
bare intervals followed by an array of decorations. How it describes
this arrangement is not our business, but we can make sure that such a
description can be understood universally across different platforms.
> 4) There is a contention about level 4 encoding.
That's precisely what I'm trying to resolve.
Michel.
---Sent: 2014-06-22 22:07:00 UTC