Re: Level 3 interchange formats (M0029.01)
Folks,
Let me suggest something that might change the nature of
this discussion.
While it IS true that it is always possible to find a
decimal string that rounds correctly to any desired
binary number, exactitude is typically lost in the
calculation. This has never been much of a problem in
floating-point but it is often critical for intervals.
However, there is a solution to this problem that can be
found among strings. It can also be found in IEEE-754
under: 5.12.3 External hexadecimal-significand character
sequences representing finite numbers.
(We did not invent it. We stole it from the C folks. :-)
Basically, there has been for some time now a standard
string for representing binary floating-point numbers as
hex strings.
It is compact, exact, & unambiguious.
And, it seems to me, it forms the basis for a natural
interchange format for binary interval data.
Does that help at all?
Yours,
Dan
> Date: Tue, 22 Nov 2011 14:46:37 -0500
> To: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> CC: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: 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