Re: formatOfMidpoint()
Michel
On 12 Feb 2012, at 02:43, Dan Zuras Intervals wrote:
> (Michel Hack wrote:)
>> It seems obvious to me that if a midpoint is not representable in the
>> target format, the result should simply be NaN. I'm using the minimal
>> definition of midpoint here: an interior point.
>
> It is less obvious to me. More on that below.
Not at all obvious to me either.
All the discussion has not changed my view that, whatever type T an interval X may be expressed in, if X is finite then the midpoint & radius in a given floating point format F should be computed *together*, by the rule
m = F-number closest to the mathematical midpoint of X (with suitable tiebreak rule);
then
r = smallest F-number such that (exact) interval [m-r,m+r] contains X.
This does funny things in some of our examples. E.g., consider Dmitry's (r;a;b) type T using the format F which is 2-digit decimal with exponent range -9 to +9. Then F's max finite number Fmax=9.9e+9.
Let
X1 = (Fmax;-1;Fmax) which is the mathematical interval [l,u] = [Fmax-1, 2*Fmax].
Its upper bound u, its exact midpoint and its exact width all overflow in the format F.
Let
X2 = (Fmax;+1;Fmax) which is the mathematical interval [l,u] = [Fmax+1, 2*Fmax].
Both its bounds, and its exact midpoint, overflow in the format F.
I think my rule above gives m=r=Fmax for both X1 and X2. But doesn't this mainly indicate that F is an inadequate format in which to measure these properties of T-intervals?
I see a good reason to return midpoint(Empty) = NaN at Level 2, but no good reason for midpoint(X1) or midpoint(X2) to return NaN.
John Pryce