Dan and all,
Yes, I agree to withdraw this motion as the seconder.
Chenyi
Dan Zuras Intervals<intervals08@xxxxxxxxxxxxxx> 05/20/10 1:00 下午
Subject: Motion P1788/M0015.01 NO
From: John Pryce<j.d.pryce@xxxxxxxxxxxx>
Date: Thu, 20 May 2010 07:34:54 +0100
To: P1788<stds-1788@xxxxxxxxxxxxxxxxx>
P1788
I have concluded that I cannot support motion 15 in its present
form so I vote No. Our rules say No-voters should state the
changes that would make them vote Yes, so here goes, below.
John Pryce
John& I have been discussing this offline for some
weeks now. And he has convinced me that there are
better approaches than that outlined in Motion 15.
We are still working out the details but I would
gladly withdraw Motion 15 in favor of an approach
along these lines.
Chenyi, as seconder, do you agree?
Baker, shall we do that?
. . .
D. Some detail
-----------
. . .
"bounded" 2 Dan's version
Purpose: Check that conceptually, overflow never occurred in the
computation path leading to an interval.
Pointwise property: Yes.
Storage needed: A single, sticky, bit.
Comment:
I think Dan's idea is this. For each (elementary) interval
operation ee(xx), let e be the corresponding point operation.
Set the sticky bit if |e(x)|> (overflow threshold), for any
x in xx, in the current precision. Dan, did I get it right?
Yes, this is correct.
It is roughly equivalent to 'overflow' in 754. But as
the names 'overflow'& 'bounded' both come with their
own conceptual baggage, my working name for this
property is 'range' with the states inRange/outRange
being the normal/exceptional states, respectively.
In the course of my discussion with John, I have come
across an example that suggests the need for something
that roughly corresponds to 754's 'underflow'. My
working name for this is 'tiny' with notTiny/tiny
being the states.
(Now that I look at them together, perhaps an appeal
to Goldilocks would be in order. With justRight/tooBig
for the one& justRight/tooSmall for the other. :-)
My query is whether this has practical uses.
John& I are still trying to work this out.
I can go so far as to state that neither is needed for
containment. (Well, I guess that's true of all of them.)
But both indicate when an interval is wider than it
should be. Sometimes vastly wider.
Having these properties available lets the user know
when this has happened. Then the user can (1) ignore it,
knowing that it is OK in this application, (2) redo the
calculation in a higher precision (with greater range),
or (3) change the way the calculation is done.
Without these properties available, the user is ignorant
of these choices.
Some other comments.
. . .
Things Michel Hack's has written suggest we should consider
including (local copies of) IEEE-754 flags among our decorations:
Michel& I seem to be thinking along similar lines.
Still, I believe that the 5 flags defined in 754 do
not translate well into interval concepts. So I am
trying to fix that.
Range& tiny as analogs of overflow& underflow are
the simplest. Perhaps, the only.
. . .
I wasn't sure from the above whether Michel envisaged repeating
the SAME CODE in some sort of debugging mode. But the following
indicates he was thinking of executing DIFFERENT CODE if the
sticky check failed.
On 26 Apr 2010, at 20:07, Michel Hack wrote:
John Pryce wrote:
(a vectorized calculation of)
c = sqrt(a^2 + b^2) (*)
where there is a problem when one or both inputs
are very large or very small. Then you would do
compute c by (*)
if overflow or underflow occurred {
re-compute c by a careful algorithm
Yes, that's precisely what I had in mind, especially in the
vector case. If the exceptions are expected to be rare, it
pays to let it run at full speed -- especially if there is
a vectorized exception summary as well (as we would like to
see for interval decorations)...
If this is an interval calculation, cc = sqrt(aa^2 + bb^2),
over/underflow shows up as bounds going to oo or 0. I guess
it's easy for an implementation to ensure the 754 flags are
set in a sensible way (in this case by "square" and "+") so
that they could be copied to a decoration if felt useful.
Is that right Michel?
This problem is a bit more subtle than you think, as
Michel well knows from our discussion of the clause 9
function hypot() during our deliberations on 754.
It is also an example of why a range decoration might
be useful. Consider
aa = [0,3e154]
bb = [1,4e154]
The correct answer is cc = [1,5e154].
But, in Binary64, the calculation cc = sqrt(aa^2 + bb^2)
will return cc = [1,+oo] even though neither of the
operands nor the result is anywhere near the overflow
threshold.
The reason for this is obvious. It is the intermediate
results aa^2& bb^2 that overflow even when the sqrt()
would bring them back down to quite ordinary numbers.
This is what my range flag is for. To tell the user
that this has happened& that the result, [1,+oo], is
unreasonably wide.
BTW, the fix for this is quite simple in floating-point.
x = maxabs(a,b);
n = minabs(a,b);
c = (x == 0.0) ? 0.0 : x*sqrt(1 + (n/x)^2)
This code fragment never has a divideByZero& only
overflows or underflows if the actual result overflows
or underflows.
A user who sees an outRange condition when doing
cc = sqrt(aa^2 + bb^2) would have the hint that is
needed to change the calculation to something like
this.
I will leave it as an exercise to the reader to find the
corresponding error free code fragment for intervals.
It is not much more complicated than the floating-point
case.
BTW, I don't remember if they were in our list of
required functions but interval versions of all of min,
max, minabs, maxabs,& hypot would be both easy&
useful, IMHO.
Enjoy,
Dan