Re: Level 3 interchange formats (M0029.01)
> I was thinking aobut the interchange format for decorations as well and
> I wanted to recommend a simple text format. Now I am fascinated by your
> idea to sacrifize 3 bits of accuracy. But can we really afford this?
It's probably a bad idea for a standard, which should permit extension
to include new capabilities. Nevertheless, the question remains: HOW
MUCH extra space should the standard allocate to decorations? A fixed
choice would be simple to describe, but could a sufficient majority
agree to, say, specifying 8 extra bytes per datum?
The attractiveness of the low-bits approach is that it preserves the
natural space assumptions for floating-point data, and it is feasible
for intervals because of the containment rule: intervals would still
be correct, though possibly a bit wider, which would become significant
only for very narrow intervals.
As I feared, the method does not work for DFP (Decimal Floating Point)
with DPD encoding, unless a two-bit decoration suffices (one bit from
each bound), which is way too restrictive. So the 10 low-order bits
of the format would have to be re-encoded before claiming some bits,
e.g. as plain binary. This is possible, but pretty far from KISS.
Btw, if we were to standardize a moderately large field for holding
decorations, perhaps we ought to take advantage of it and make it
self-describing. This would involve putting the decoration field
first, so that it describes the format that follows. An additional
benefit of this approach would come from including an explicit size
field, so that padding for alignment purposes could be variable.
With Binary64 floaters, the minimum size might be 20 bytes, but one
could specify 32 bytes for optimal alignment -- in a standard and
portable manner.
WITHIN a platform all sorts of means to store interval data externally
would be possible. A meta-description scheme could be standardized to
describe the layout of an entire file, for example: this could even
handle storing decorations separately (at a different offset in the
same file as the numeric portion or portions). Such a scheme would
permit exporting the raw file, because the information needed to
transform it to a different representation would be present in a
standard form.
Michel.
---Sent: 2011-11-22 20:14:35 UTC