Re: Discussion about accuracy modes
Dan Zuras wrote:
Attached is a PDF that attempts to illustrate some of these points.
Notice
in this figure that accuracy modes are largely determined by whether the
interval type has fixed range and precision or not, as opposed to whether
the interval type is explicit or implicit. Alternatively, we could use
the
proposed definiton for implicit type in Motion 19. In that case, some
mid-rad types (e.g., the ones depicted with fixed range and precision)
could
be "made" explicit by providing some suitable definition of unique hull.
. . .
In any case, these are the thoughts that have been on my mind lately
regarding these topics. I'm wondering what others think?
Sincerely,
Nate
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