| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dan Zuras wrote:
What about one more example (again in two-digit floating-point decimal numb= ers) ? [u,v] = [0.92,1.2] midpoint([u,v]) = roundNear((u + v)/2) = roundNear((0.92 + 1.2)/2) = = roundNear(1.06) = 1.1 radius([u,v]) = roundUp((v - u)/2) = roundUp((1.2 - 0.92)/2) = roundU= p(0.14) = 0.14 [roundDown(midpoint(X) - radius(X)), roundUp(midpoint(X) + radius(X))] = = [roundDown(1.1 - 0.14), roundUp(1.1 + 0.14)] = [roundDown(0.96), roundUp(1.24)] = [0.96, 1.3] The property ([0.92,1.2] \subset [0.96, 1.3]) is false.Now, THAT'S a good example. OK, we're wrong. (I'm wrong. I had to convince Nate. :-)
Yes, I had some cold feet about this one :-) But I note that Dmitry's radius formula seems to obey property (18), too (am I wrong?) Dmitry Ndezhin wrote:
There tightest radius(X) satisfing (22) is: radius([u,v]) = roundUp(max(midpoint([u,v]) - u, v - midpoint([u,v]))) . (*) However, it is necessary to explore if it can be implemented efficiently.
I spent some time looking at a smiliar formula on Saturday. If m = midpoint([u,v]) then I had come up with: radius([u,v]) = max(abs(roundDown(u-m)),abs(roundUp(v-m))) (**) But your formula (*) above is better, since it recognizes v-m is always positive and u-m is always negative, hence saving two absolute values and a rounding mode switch. My main question is can we always assume optimzation (*) works over more general definition (**) for every conceivable floating-point representation (even non-IEEE 754 formats)? Or should we specify (**) but let implementers choose optimzation (*) if it is safe for thier particular floating-point formats? Otherwise its hard for me to think how (*) or (**) might be implemented more efficiently. Nate