Re: Level 2 query, number 2
Michel, Baker, Dan, P1788
I basically agree with Michel's analysis, but have some queries I shall send in a separate email.
On 5 Sep 2011, at 14:03, Michel Hack wrote:
> 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.
Please clarify "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
I agree.
> -- 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.
I agree. I suppose the tag might include one such as "Chipmunk" for a proprietary format supplied by the Chipmunk Intervals company.
I don't see it as practical for P1788 to define "a generic format that can represent almost anything", in view of the wide variety of formats discussed in the forum, especially for multi-precision work. I suppose we could have a _recommended_ form such as integer*(base^exponent) (above), and say "use this if you can, otherwise document it as you find necessary".
> 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.
Good example.
John Pryce