Re: Discussion about accuracy modes
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: "P-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Discussion about accuracy modes
> Date: Tue, 24 Aug 2010 14:46:32 -0500
Vincent,
Care to join us for a swim?
The waters are friendly today.
Specifically, would you care to opine on how we might
specify the behavior of potentially infinite interval
datatypes?
Dan
>
> Dan Zuras wrote:
> >>
> >> . . .
> >>
> >
> > Ah, I think I understand now.
> >
> > You think of variable precision interval types as a single
> > datatype which is a subset of the datatype of potentially
> > infinite range & precision. This is something Vincent has
> > named effectively or practically infinite. (I forget his
> > exact words.)
> >
> > Yes, if you considered such a thing to be a candidate
> > datatype for 1788 then it would be implicit.
>
> Right... at least, by the proposed Motion 19 definition that
> an implicit type has no unique hull.
>
> A related observation is that such an implicit variable-precision
> type can't have a "tightest" accuracy mode. However, the reason
> for this seems to be mostly due to the variable-precision nature
> of the interval, not the implicit nature.
>
>
>
> > Now, while I think we must include variable precision
> > intervals, I don't think we should consider them to be
> > one large datatype for just this reason.
> >
> > In order to properly specify their behavior I think we
> > must consider each instantiation of precision & range
> > (or precisions & ranges, in the case of heterogeneous
> > mid-rad forms) to be a single datatype. It can be
> > either explicit or implicit, as is your want.
> >
> > Then, when one performs an operation that changes the
> > precision of the result it must be considered as an
> > effective type conversion to another type. It is exact
> > when moving up & enclosing & possibly inexact when
> > moving down.
> >
> > The result is then specified according to the rules in
> > the new datatype.
> >
> > Accuracy modes might enter into it as well but that has
> > nothing to do with the specifications of the datatype
> > itself.
> >
> > Now, I must admit that Vincent & I never finished our
> > discussion of this issue. Perhaps he does not agree.
> >
> > If so, we are left with the problem of specifying the
> > behavior of potentially infinite datatypes.
> >
> > Either that or eliminating them from the standard
> > completely.
> >
> > I would rather not do that.
> >
> > Your thoughts?
>
>
> I would rather not eliminate them from the standard, either.
> It seems we are very close to having our cake and eating, too.
> Just a little more effort, and it should all fall into place
> (at least, that is my impression).
>
> Now, what approach is most appropriate: what you mention above
> or Vincent's counter-position? I'm not sure yet, but I'd be
> interested to watch you both finish that discussion.
>
> In terms of the bigger picture, I'd say the Accuracy Modes PDF
> I posted has all the relevant "players" of the game. Perhaps
> the matrix depicted needs a little tweaking, or perhaps some
> of our definitions do. I'm not sure. But I see all the pieces
> of the puzzle are depicted there.
>
> And, remarkably, they seem to be fitting together quite nicely,
> IMHO.
>
> But I'm interested to hear what other people think.
>
> Nate
>