Re: Why (IMO) you should vote Yes to Motion 14.02
> Subject: Re: Why (IMO) you should vote Yes to Motion 14.02
> To: stds-1788@xxxxxxxxxxxxxxxxx
> Cc: Christian Keil <c.keil@xxxxxxxxxxxxx>
> From: Ian McIntosh <ianm@xxxxxxxxxx>
> Date: Mon, 28 Jun 2010 16:01:54 -0400
>
> Christian Keil wrote:
>
> CK> ... If I read it correctly,
> CK> Motion 14 does not rule out mid-rad intervals. The only thing it says
> CK> (leaving the title of 6.1 aside for the moment) is that the bounds must
> CK> be retrieved exactly, but it doesn't specify the nature of the level 2
> CK> datum. Additionally it mentions multi-precision representation of
> CK> intervals by the triple (x_hat, delta_l, delta_u) to be conforming.
> CK> Therefor a mid-rad representation seems to be conforming to these
> CK> requirements. ...
>
> Pick an interval in which the least significant bit of the lower bound is
> 0, the least significant bit of the upper bound is 1, and all other bits of
> the lower and upper bounds are identical.
>
> With a mid-rad representation, the mean should be halfway between those,
> and the radius should be a normalized form of the same exponent but a
> fraction of all 0 bits then a 1 bit to the right of the least significant.
>
> Those mean and radius are not always representable. An obvious group is
> when the bounds are subnormals and the exponent can't be adjusted.
>
> So requiring that the lower and upper bounds always be retrieved exactly
> seems to exclude mid-rad, unless the mid-rad uses higher precision.
>
> - Ian McIntosh IBM Canada Lab Compiler Back End Support
> and Development
>
Ian is quite correct in his example. It is eloquently
stated & undeniable.
However, it does not follow that mid-rad forms are to
be excluded for this reason.
First, Ian's example goes to the issue of trying to
exactly map an inf-sup interval onto a mid-rad form.
And he is correct that it is not always possible.
But the text of 6.1 only requires that the extraction
of upper & lower bounds be exact. Were the original
format some flavor of the inf-sup type, this would be
trivial.
Therefore, the text of 6.1 speaks to the implementer
of other forms, mid-rad being only one possible
example.
The question then becomes: Can we represent intervals
in some sort of mid-rad form & STILL extract the
bounds exactly?
As we all know, calculating mid +/- rad might involve
a roundoff error. As such, there might exist a
(mid1,rad1) & (mid2,rad2) such that BOTH map onto the
same inf-sup pair. This would mean that these two
DIFFERENT intervals are indistinguishable to the user
except for the fact that they behave differently in
calculations.
Lying to the user in this way is what 6.1 is trying
to avoid.
But in a mid-rad form that admits both (mid1,rad1) &
(mid2,rad2) as elements, how is this to be avoided?
There may be many ways, some better than others.
One way, off the top of my head, is that instead of
storing mid1 & rad1 when they come up in a computation,
store the following:
mid = mid1;
rad = roundAway(mid + rad1) - mid;
This has the property that mid +/- rad may now be
exactly extracted at the cost of two adds & a slight
increase in radius.
It cures our problem. As either (mid1,rad1) &
(mid2,rad2) map onto the same representation or they
do not. Either way, the user is not lied to about
their nature.
I don't know if its the best way but it is ONE way.
I don't know if it should be done for all intermediate
calculations or only those that the user can see via
the means of the extraction of upper & lower bounds.
I suspect the latter is sufficient but I'm not sure.
I don't know if the requirement for exact extraction
places an undue burden on conforming mid-rad forms.
But if the maxim of interval principles is "Do not lie"
then I believe that we should not tell the user that
two different intervals are the same interval.
This is the caveat I spoke of earlier.
This is the meaning of 6.1.
This is why it is neither trivial nor exclusive of the
mid-rad forms.
And this is why it is worthy of a serious discussion
of its merits rather than the irrelevancies discussed
so far.
It is also an example of one of the hard (some might
say, arbitrary) rules we have to decide on if we are
to create a community of common interval concepts.
It will not be easy.
But it must be done.
Dan