Level 2 query, number 2
P1788
As I wrote, I am redrafting Level 2 text.
A topic where I/O, motion 17, overlaps with Explicit/Implicit interval types, motion 19, is:
Exact conversion of an interval of any type to text.
This is different from the topic of text to interval conversion, as discussed, e.g., in Vienna proposal part 6 and at various times in the forum.
These are the issues as I see them.
1. Every (bare) interval type T must have a loss-free way to write any datum (i.e. interval) in T as text, and to read that text back to recover the original datum exactly.
2. It must be straightforward for a human to discover from that text (with the aid of a standard calculator, or Matlab, Maple, etc.) what mathematical interval the datum represents.
3. One reason is to use it for data interchange, but I have a more fundamental reason. Since we've permitted non-IEEE754 interval types, and implicit types, implementers have huge freedom. If they invent some weird and wonderful representation, and it is for public use, they must "explain what the representation is".
I find it hard to say just what I mean by the phrase "explain what the representation is". But it includes making it possible for a user to follow, via the text form, EXACTLY what intervals are being stored and the result of each arithmetic operation, e.g. in order to run correctness tests.
On the other hand it shouldn't force an implementer to disclose commercially sensitive information.
4. The text form must either be self-explanatory (unlikely) or be explained by the implementer, so an essential part of the requirement is DOCUMENTATION.
5. Some examples from floating point, say an IEEE binary64 datum x:
5a Dump x's bit string as 16 hex digits. This says exactly what's there,
but doesn't say what it means.
I don't like this solution: it's not user-friendly, except for geeks.
5b Write x in decimal FP to 17 (or is it 18?) significant figures,
correctly rounded. It is known that the binary64 form can be
recovered uniquely by reading this decimal number back.
I don't like this solution much: the decimal string is rather
far removed from the datum.
5c Write x using C's "a" conversion specifier, giving a string like
+0x1.23456789abcde p-04, which extracts the sign, exponent and
significand in a friendly way from which the bit string can easily
be reconstructed.
I like this solution.
Example: A mid-rad form that uses binary64 for the midpoint m and binary32 for the radius r might use a text form similar to 5c, like
+0x1.23456789abcde p+00 +- 0x2.34567 p-04
On the principle of Occam's razor, can the standard take the view that the text form, plus an explanation of it, is ALL that implementers need to disclose? I.e. they say "Here is a set of text strings. They are in 1-1 correspondence with the members of an internal (Level 3) interval format whose details I don't need to tell you. Here's the algorithm for finding the mathematical interval represented by any string in the set."
Well, there's one extra thing. "Here's the algorithm for finding the interval hull of any set of real numbers."
Please point out any flaws in this. If it seems OK would someone like to word it succinctly? Michel Hack perhaps?
Regards
John Pryce