Re: Level 2 query, number 2
John Pryce wrote:
> Using the same method for intervals in the obvious way, xx = [0.25,0.625]
> converts to "[.3, .6]" converts back to xx. The fact that the interval
> [.3, .6] doesn't enclose xx is irrelevant. This particular text
> representation wasn't intended to be interpreted that way.
All I was trying to ensure was that there be a distinction between external
representations used for export/import and unqualified string representations.
And in order to ensure that import preserves the properties expected by export
it is necessary to tag the representation with something that identifies the
source format -- UNLESS the exported representation is EXACT.
So there we are:
(1) Export to a convenient and well-understood generic format, but tagged
with a description of the source format, in the sense John mentioned:
sufficient to define unambiguously the mathematical values involved.
(For example: fixed-precision n-bit binary with exponent range min
max, or a public format name such as Binary64.)
(2) Export exactly, documenting the format, or letting us define a generic
format that can represent almost anything, e.g. an arbitrary expression
such as integer*(base^exponent) for relatively simple formats, or more
complicated expressions for, say, level-index formats.
Neither method requires exposing proprietary details of the internal encoding.
It is the external format that must be documented unambiguously.
Both forms can indeed be seen as a contract. To illustrate a practical case
where such a contract is needed, consider the double+double format used on
IBM PowerPC for "long double". Mathematically this has variable precision,
but the contract would say that a precision of 106 bits is enforced by the
import/export mechanism. This is in fact the position I took when I wrote
the conversions between BFP and DFP for AIX.
Michel.
P.S. "Tagged" does not require tagging each datum. The tag could apply
to an entire list, without prejudice -- but the standard would have
to say that.
---Sent: 2011-09-05 13:34:11 UTC