Re: How do I bisect unbounded intervals?
Folks,
While I sympathize with Vincent's feelings in this
matter, I hesitate to follow 754 in the "formatOf"
direction.
Vincent's motivation in this is to solve problems
that limited range & precision present to the user.
However, it may be that the typical 1788 user has
only one interval type to choose from. And only
one floating-point type to support it. Or at the
very least, both the interval & floating-point
types are ALREADY the widest & most precise available.
In that context, providing formatOf functions to the
user solves nothing & presents us (as standards writers)
with a world of hurt you can only dimly see from your
vantage point.
Let us not add such complexity in the hope of solving
problems we will not solve. It is better to find
other ways.
IMHO, of course.
Dan
> Date: Wed, 18 Jan 2012 01:59:29 +0100
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: How do I bisect unbounded intervals?
>
> On 2012-01-17 17:40:16 +0000, John Pryce wrote:
> > On 17 Jan 2012, at 12:43, Vincent Lefevre 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).
> >
> > I proposed long ago that, ONLY for inf-sup types derived from
> > IEEE754 formats, all _interval arithmetic operations_ should be
> > available in "formatOf" mode (this is what §5.4.1 is about).
> >
> > Vincent, your comment suggests we should extend this feature from
> > arithmetic operations to numeric functions of intervals. Would that
> > do what you think is needed?
>
> I think it would make sense and be consistent to interval arithmetic
> operations and also the IEEE-754 formatOf operations.
>
> > >>> ...
> > >> (John Pryce wrote:)
> > >>> 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.
> > >>>
> > >>> For each implemented T, each numeric operation on intervals shall
> > >>> have a T-version that returns a result of this T-format. (One might
> > >>> allow different operations to return results of different formats,
> > >>> but to me that seems way too complicated.)
> > >>
> > >> I would not associate a T-format with the interval type T.
> >
> > If we don't, how are we to define numeric functions of intervals,
> > for types that are not inf-sup? For a general implicit type T there
> > is NO intrinsic way to associate a number format; IMO it must be
> > specified as part of T's definition.
>
> 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)