Re: MidRad to/from InfSup (was: the "set paradigm" is harmful)
On 12 Feb 2009 at 10:06, Michel Hack wrote:
...
> Things are not quite that simple; we also have to worry about edge
> cases. Unbounded InfSup cases need to be handled separately (Arnold
> proposes that the "midpoint" be the smallest-magnitude member of the
> interval, the radius being +Infinity), but we also have to worry about
> overflow in u+l, which Arnold's revised formula mostly avoids. There
> can be overflow in (u-l) too, but in that case the radius computation
> would overflow too. Consider conversion of [Max, ulp-Max], whose true
> midpoint is (representable) ulp/2 (of a Max-sized value), but the
> corresponding radius would be Max+ulp (not representable), so one would
> have to return m=0, r=Max instead (aka Entire).
>
> Michel.
>
> P.S. I just realised that Arnold's rule for strictly one-signed unbounded
> intervals leads to an entire family of Entire MidRad intervals with
> the same infinite radius, but different "midpoints".)
>
> Is there any agreement in the MidRad community for dealing with
> overflow and/or unbounded intervals?
> Sent: 2009-02-12 15:32:57 UTC
IMO one should not worry about specifying midrad fp-operations
for edge cases involving wide intervals. This is simply useless.
Midrad interval arithmetic is intended for narrow intervals in order
to model computations with approximate numbers.
One only has to define what is a narrow interval. Generally speaking those
are intervals for which no unpleasant effects (of the sort that Arnold
mentions) exist.
I think that the first such unpleasant effect appears when r>(sqrt 2 - 1) m,
since then the centred square of a positive interval contains negative
numbers. In practice this means that an interval is narrow, if r<= 0.4 m.
Restricting computations to narrow intervals will mean in practice that results
should be checked at each step for narrowness. However, this can be an
extremely fast process as it can involve only the exponents of r and m. This,
combined a 1-2 digit mantissa for r will lead to a very fast midrad arithmetic.
Regards,
svetoslav