Re: How do I bisect unbounded intervals?
On 2012-01-18 13:40:02 -0500, Michel Hack wrote:
> On Tue, 17 Jan 2012 13:43:35 +0100, Vincent Lef?vre wrote:
> > I would not associate a T-format with the interval type T.
> > For instance, for a binary64-based inf-sup interval type T, one may
> > want the midpoint in binary64, but also in binary128, as allowed by
> > IEEE 754 (?5.4.1).
>
> Then, on Tue, 17 Jan 2012 15:01:54 +0100:
> > On 2012-01-17 07:15:07 -0600, Ralph Baker Kearfott wrote:
> >> That's an interesting thought. Can you elaborate on why one might
> >> want more precision in mid than in the end points?
> >
> > In some cases (in particular for not too large intervals, which
> > are cases for which the midpoint is most interesting), this would
> > allow one to get the exact result.
>
> And on Wed, 18 Jan 2012 01:59:29 +0100:
> > I think it would make sense and be consistent to interval arithmetic
> > operations and also the IEEE-754 formatOf operations.
>
> To which Dan Zuras replied:
> > While I sympathize with Vincent's feelings in this
> > matter, I hesitate to follow 754 in the "formatOf"
> > direction.
>
> There is another way to deal with this: If you want a higher-resolution
> midpoint, first convert the *Interval* to wider precision, then take its
> midpoint.
But the higher precision may not be available as an interval type.
And what if the implicit type is quite abstract, so that no notion
of precision is associated with it? Say, intervals with rational
bounds? Associating a normal format with it would be quite artificial.
If you associate with it only the number format having the largest
precision and want the midpoint in a lower precision, you'll suffer
from double rounding.
> That would fit with the T-format approach recommended by John
> Pryce on Mon, 16 Jan 2012 22:25:49 +0000:
>
> | ...How do midpoint and the other numeric functions
> | of intervals work for an _implicit_ type?
> |
> |I've basically defined an interval type T as a set of mathematical
> |intervals plus a specified T-hull operation. No number-format is
> |mentioned. But Level 2 midpoint, etc., must return a datum of some
> |number format. Hence I see nothing for it but to make the revised
> |definition:
> |
> | An interval type T is a set of mathematical intervals,
> | plus a specified T-hull operation, plus a specified
> | number format, let's call it the T-format.
>
> You see, John was concerned about implicit types, and subsequent discussions
> reminded us that implicit types could encode their information in all sorts
> of different ways. Yet common functions like mid() and rad() applied to
> any interval type should return something in an explicitly-defined format.
>
> When multiple FP precisions are supported, it makes sense to me to expect
> formatOf versions, either explicit (like mid64(), rad32() etc.) or (in a
> language where types can be overloaded) implicit, depending on the format
> of the source operands. This would in particular avoid double-rounding
> issues, which is the primary reason that 754-2008 took that route.
But John's approach forbids that because it associates only one
number format with the type! Allowing one to specify the format
was what I proposed on Wed, 18 Jan 2012 01:59:29 +0100:
|The number format would have to be specified in the function. How it
|is specified (possibly implicitly) would be implementation-defined
|or language-defined. Basically, this means that we should not enforce
|a privileged number format associated with a type T; a default number
|format associated with a type T is allowed but should not be required.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)