| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
On 6/8/13 5:27 PM, Richard Fateman wrote:
On 6/8/2013 6:32 AM, John Pryce wrote:Jürgen and P1788
Now it is entirely possible that someone would endorse the creation of IL, as a machine independent logically complete interval arithmetic implementation.It would depend solely on manipulation of strings.At perhaps the opposite extreme that is at all plausible, would be an interval arithmetic "implementation" which does arithmetic on pairs, but ignores therequirements of valid containment via directed rounding etc. This would be so sloppy that this clearly would not pass muster.
The former environment existed with BCD arithmetic before about 1965 when IBM introduced floating-point arithmetic for speed and in the process, by giving up fixed point arithmetic, lost the ability to preserve accuracy information in trailing decimal zeros.
An interval system in this environment could avoid any outward rounding at the cost of long strings of digits and speed.
However, speed is a "quality of implementation feature" (a phrase I coined *) that to my knowledge is not a requirement of any standard. Fast is good. It is a figure of merit with which different vendors compete.
For us interval types, there is another quality of implementation feature: interval width. Narrow is good, but too narrow is a fatal error that must never be committed. This is prevented by the containment constraint that must never be violated.
So, a hypothetical BCD interval implementation could produce perfectly narrow intervals, but be so slow as to be impractical for most applications.
In my view, the other extreme is not the one you mention, but rather would be an interval implementation that is blisteringly fast and never violates the containment constraint by returning [-inf, +inf] for every computation. Totally useless.
So, the tradeoff, in my view is between speed and width, while never violating the containment constraint.
As with speed, I also believe narrow width is a quality of implementation feature and therefore should not be part of an interval standard, other than to make clear that narrow is good, provided the containment constraint is never violated.
So, this view leads to not requiring any particular radix or I/O conversions for intervals and leaving both these features to be qualities of implementation.
One side benefit is standard simplicity, which I believe will increase the likelihood it is accepted and adopted. Too many baroque requirements will surely turn off implementers and stifle implementer creativity.
* Walster, G. W., "The use and implementation of interval data types", Chapter 9 in "Accuracy and Reliability in Scientific Computing", July, 2005, See: <http://www.nsc.liu.se/wg25/book/>
Cheers, Bill