Re: P1788 input/output

[John Pryce <prycejd1@xxxxxxxxxxxxx>]

Vincent, P1788

This query by Vincent is ambiguous:

On 2013 Jun 28, at 13:18, Vincent Lefevre wrote:
> Moreover I suppose that if T is a subset of T' and x is an interval
> of type T (so that hull_T'(x) = x), it is *not* required that
> 
>  public2interval(interval2public(x),T') = x
> 
> i.e. the behavior of interval2public is strongly type-dependent, not
> based on a Level 1 function. But perhaps the above equality should be
> recommended.
In the latest draft I renamed these as exact2interval and interval2exact. So the query is: If
(*)  s = interval2exact(x)  (x is a T-interval so this means T-interval2exact(x))
then is
(**)  x' = T'-exact2interval(s)
equal to x ?

Well, "no" in the normal sense of Level 2 equality because equal(x,x') is simply undefined when x and x' have different types. BTW Vincent's hull_T'(x) = x above has no meaning at Level 2 for that reason.

But should be "yes" at Level 1 since (*) maps x to an exact text encoding of its Level 1 value, and (**) should recover this value.

But actually "maybe" (this is a *design decision*). I think it's what Vincent really means. Namely, T'-exact2interval(s) is guaranteed to be defined, and equal x', when string s is produced by T'-interval2exact applied to a T'-interval x'. But it needn't even be *defined* for the s from (*), which is produced by T-interval2exact.

Here's an example to fix ideas. 
Let T be inf-sup binary32. 
Let T' be inf-sup binary64.
So T is a subset of T'. 
Let x = [xlo,xhi] be a nonempty interval of type T or T'.
Then s = interval2exact(x), is "[slo, shi]" (meaning concatenation of "[" slo "," shi "]" ) where strings slo, shi are the result of outputting xlo and xhi in hex-significand form with enough digits to represent them exactly, which I think is 6 digits for T and 14 digits for T'. So s for x of type T might be
    s = "[6.789abp+5, 7.89abcp+5]"
and for x of type T' the (mathematically same) interval might be output as
    s' = "[6.789ab00000000p+5, 7.89abc00000000p+5]"
if the implementation decided always to print the full number of hex digits, and not suppress trailing zeros.
(Recall p+5 means "times (two raised to power 5)" where the 5 is decimal.)

Should T'-exact2interval() be able to read s? Should T-exact2interval() be able to read s'? My view is Yes. In fact the current draft of I/O says that for 754-conforming types, T-exact2interval() is the same as T-text2interval() (for any type T), so it can read any interval literal, so it can read s or s' equally well.

Is that sensible?

A follow-up query is whether a (new? change to existing?) Level 2 equality-comparison operation is needed to test equal(x,x') when x,x' are of different types, one being a subset of the other. Relevant especially for 754-conforming types, as above.

John Pryce