MidRad to/from InfSup (was: the "set paradigm" is harmful)
I'm glad John Pryce exercised those back-and-forth conversions a bit.
I had started to do it, especially around powers of the base (which
is where things can get tricky because of the jump in ulp size), but
it is so easy for little mistakes to slip in unless I first wrote a
little program to verify the arithmetic, so I chickened out.
>> I think back-and-forth conversion would be stable after one round.
>
>I think that isn't so. Using 4-digit decimal floating point I got
> 0.9997-+ 0.0003100
> -> [0.9993, 1.001]
> -> 1.000-+0.0008500
> -> [0.9991, 1.001]
> -> 1.000-+0.0009500
> -> [ 0.9990, 1.001]
> -> 1.000-+0.001000
I would have done the conversion differently: having found the exact
midpoint 1.00015 of [0.9993, 1.001], I would have first rounded it to
the floating-point number 1.000, at which point the radius needed to
cover both endpoints would have been 0.001 -- and stability would have
been achieved after one round. John derived the radius 0.00085 from
the exact midpoint, not the rounded one. John's is tighter, and also
valid (i.e. the interval contains the original one), so it is better,
but which one should be required by the standard?
Well, the Vienna Proposal states:
| If xx=[l,u] is compact, m and r shall have the values defined by
| set round up
| r = 0.5*(u-l);m=l+r.
That does give John's radius of 0.00085, but the midpoint has to be
rounded up to 1.001; it should not be picked arbitrarily. It leads
to a third sequence of conversions:
0.9997-+ 0.0003100
-> [0.9993, 1.001] So far we should all agree
-> 1.001-+0.0008500 Midpoint rounded up
-> [1.000 , 1.002] Oops! Does not enclose the original.
-> 1.001-+0.001000
-> [1.001 , 1.002] Stable but wrong
Ouch! Did I goof, or does the Vienna formula have a problem?
I note that John's method is implementable if fma is used to derive
the radius from the midpoint.
Michel.
Sent: 2009-02-11 15:44:47 UTC