| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Ulrich (and others)
Setting a standard that can only be achieved by custom hardware is neither necessary nor, it seems to me, advisable. By repeatedly emphasizing the hardware aspect of EDP implementation (although of course it can be more slowly in software) you raise the prospect that people will think that the 1788 standard requires special hardware or can only be efficiently implemented with special hardware. This would be, I think, unfortunate. An understanding of techniques to ameliorate software bottlenecks so that we might achieve the results dictated by the standard using existing commercial hardware and programming languages and libraries is, in my opinion, important for the viability of the standard. Some of this has been vastly simplified by the convergence of floating-point hardware specifications. There remain significant barriers in some programming languages, compiler tools, and libraries, in my view. Finding a pathway through these issues for implementers and users of interval arithmetic is, I think, important. While in the past different manufacturers had divergent floating-point hardware and the IEEE 754 standard "cleared the air", I am unaware of any commercial processor manufacturer who has incorporated in hardware any operations that are specifically interval-related in such a fashion as to exclude any of the variants of interval arithmetic of interest. This committee is, it seems, an unlikely place to demand a standard that requires new hardware that no one is building. In spite of the apparent success of the IEEE 754 standard, note that some manufacturers and software language developers (most?) have implementations in which fundamental operations are slow, inconvenient, and occasionally impossible to achieve, such as setting rounding modes or working with traps and NaNs. Some of these operations are of course key to implementing interval arithmetic. I point this out to illustrate that we are not in the driver's seat in regard to hardware changes, even in that much more compelling case of a need for floating-point standards -- implemented efficiently. For instance, it might lead to substantial interval-arithmetic efficiencies if hardware dealt efficiently dealt with rounding modes. One proposal would have instructions sets that included extended-float-add-register-rounding-up etc. Thus there are many opportunities for efficiency in hardware that could improve performance on interval tasks, as well as other floating-point related processing. I think that the interval standard document is sufficiently complicated without discussions of hardware. I do not expect that this will change your enthusiasm for hardware EDP. Nevertheless, I hope this note explains why I would prefer that the value of EDP toward a standard, if it is to be included in the document, be explained on grounds of its contribution to achieving computational results. I think that any comments regarding special efficient hardware be relegated to -at best- a footnote and references. Regards. Richard On 1/16/2016 3:11 AM, Ulrich Kulisch wrote:
|