| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Folks, On 20.05.2010 19:57, Dan Zuras Intervals wrote: [...]
"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?
[...]
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.
I'd love to see some practical example on this. My feeling is with John's impression. Sure, you might be missing the direct indication of an over- or underflow but 1) I'm not convinced that these (to me seemingly corner) cases appear often enough to justify carrying that prit, 2) the user will find that his computation is lacking if the results are not satisfactory in which case he has to take action---as in all numerical computations; also see below on this.
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.
I know that finding good examples is difficult and convincing ones even more so. I wrote more than once of gut feelings with "I cannot come up with an example..." And please don't take this as an incentive not to give examples because practical examples and applications should (shall =)?) be the driving factor in our standard! And I may well be missing something here.
Enough for the disclaimer. Maybe we come back to the target audience and experience of our clientele on this one. My experience would tell me that above intervals are rather large for interval applications. I know it's an example but I cannot come up with a scenario in which case a user would draw information from cc.
So let's assume that we specify some domain aa and bb and do a B&B on it. In this case I'd say "grab a coffee that might take a couple of minutes depending on the speed of your CPU" aka "your search region is too large"---I'm no expert on B&B so correct me if I'm wrong.
Now using the given formula of course yields [1,+oo]. What kind of audience do we expect to have. Do we expect considerably less expertise of our users than of writers of FP code? My feeling is that overflow in such cases does not belong to the real intricacies of FP that may lead to completely wrong results out of subtleties---I know these may be as artificially constructed as I criticized above. Expecting a good result here---I know Dan didn't expect this in the example---puts quite a burden and complexity on the implementation of the standard.
Finally the result [1,+oo] shows that something went wrong. I'd expect that users of our standard would have some intuition on the correct result. How are they supposed to recognize errors in their modeling? We guard them from errors introduced through rounding and approximate algorithms. But we cannot guard against errors in the implementation of floating point operations we rely on like adding the bounds of an interval. We cannot guard against errors in the CPU nor bits flipping in memory. The user has to have an idea of the correct result to judge the result of the computation and take proper action to improve his program if the results are bad.
My 2 cents on this... Are they well spent or invested in bad bank's stocks? Christian