| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Vincent, dear John, Let me try to answer some arguments that I got with recent mails. >---- The standard does not require or mandate that any operations be implemented in hardware. Of ocurse we should no require or mandate that any operations be implemented in hardware. But developing the standard we should have the possibilities of today's hardware in mind. It would be a tragic mistake if we would develop the standard for the technology of 1980. Modern processors provide registers for words of 128 bits. They can hold pairs of double precision floating-point numbers. They can be viewed as bounds of intervals. Parallel operations like +, -, ×, /, min, max, and compare can be performed on these pairs of numbers. Even shuffling of bounds is possible and all data paths are available for computing the lower and upper bound of the result of an interval operation simultaneously (in parallel). All that is missing is rounding the result for the lower bound downwads and for the upper bound upwards. So I have no difficulty requesting that modern processors should compute the upper and the lower bound of an interval operation simultaneously. The case selctions for interval multiplicaton (9 cases) and division (14 cases) can be done in hardware with no time penalty! This would be a great speed up for interval arithmetic. The interval literature is full of tricky, clever, and most intelligent considerations of how to overcome the deficiencies for interval arithmetic of the 1985 standard IEEE754. In the past intervallers had to take processors as they are and try to make the best of them. Developing a standard for interval arithmetic gives us a chance for leaving the need for these studies behind and adapt the properties of the processor more to the need of interval arithmetic. >---- Concerning the exact dot product, I propose to suggsest the inclusion in the next IEEE754 revision first, before considering it for 1788. Dramtic advances in computer technology, in memory size, and speed have been made since 1985. Arithmetic speed has gone from megaflops (106 flops) to petaflops (1015 flops). Problems that are dealt with are getting larger and larger. For adopting this situation the revised standard IEEE754 (2008) provides another floating-point format of 128 bits. This is not really useful for interval arithmetic. For large intervals there is no need describing the interval bounds with more than 30 decimal digits. I think 99% of the users would be satisfied with double precision bounds (16 decimal digits). And for small intervals describing each bound by 128 bits would be a waste of silicon and computing time. It would be better representing such an interval as [x] := x + X, where x is a double precision floating-point number and X is a double precision interval. This would considerably speed up and simplify the arithmetic for small quadruple precision intervals. I am now going to extend this idea. For interval evaluation of an algorithm (a sequence of arithmetic operations) in the real number field an old result of interval arithmetic says roughly that increasing the precision by k digits reduces the error bound by b-k, i.e., results can always be guaranteed to a number of correct digits by using variable precision interval arithmetic. Intervallers dream of this kind of applications for half a century. A long interval of length n is defined as a sum [x] := x1 + x2 + ... + xn + X. Here the xi, i = 1(1)n, n >= 0, are double precision floating-point numbers and X is a double precision interval. Arithmetic for such multiple precision intervals is defined and can simply be used by operator overloading (in C-XSC for instance). With increasing width of the interval [x] the word length decreases. This variable precision interval arithmetic is the interval arithmetic equivalent to extending the word length in floating-point arithmetic. (See, for instance, my book Computer Arithmetic and Validity, de Gruyter 2008, or the nice article by Blomquist et al. in the proceedings of the Dagstuhl Seminar 2008, Springer LNCS 5492, 2009, [5] on the poster). I think that everybody of P1788 can imagine without going into further detail that the central building block for such variable precision interval arithmetic is an exact dot product. Waiting until another revision of IEEE754 provides it would postpone interval arihmetic from being more widely and successfully used perhaps for decades. >---- Also, the exact dot product isn't as simple as described with a large exponent range. Motion 9 says: An implementation shall at least provide it corresponding to binary64 if it provides binary floating-point and decimal64 if it provides decimal floating-point. ... It may provide more... See my poster for how computing the exact dot product in software or hardware. What can be done in the cases of larger exponent ranges is discussed in my book. Let me summarize what has been said: To adapt the computer more to the needs of interval arithmetic two requirements are needed: I. fast hardware support for interval arithmetic (easy obtainable on existing processors), and II. a fast and exact multiply and accumulate operation (continued addition), or what is equivalent to it, an exact scalar product (for the double precision format. For a simple sketch see the poster). Both are basic arithmetic operations for interval arithmetic and should be listed as such in the document. Let me make another remark: Arithmetic for extended real intervals (closed and connected sets of real numbers) is free of exceptions. So a standard for interval arithmetic could be greatly simplified by a more strict separation form IEEE754 for floating-point arithmetic (no automatic type transfer from floating-point to interval). Best regards Ulrich Am 08.02.2012 15:07, schrieb Vincent Lefevre: On 2012-02-07 13:04:09 -0600, Ralph Baker Kearfott wrote:John, Ulrich, et al, I'm not sure where the disagreement is, and it seems like there is a bit of misunderstanding. In particular, motion 9, see http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html passed, and it says that the dot product will be in the standard. Thus, the argument must be related to how or where it is specified in the actual standards document. Regarding "exact" vs "accurate" or "faithful" dot product, this is still an element of informal, offline discussion. The title of Motion 9 was "exact dot product," so I assume this is what we voted on. (My link to the motion itself comes up blank.) The position paper is a description of uses of the dot product, but is not written as a motion, so it is not immediately apparent what the standard is to mandate. At the risk of delaying voting on the standard text, I wonder if someone would like to proffer a clarifying motion.I think that P1788 should not do the job of 754. I even wonder whether it is allowed to specify things from the domain of the others standards (such as 754 and language standards). Concerning the exact dot product, I propose to suggest the inclusion in the next IEEE 754 revision first, before considering it for 1788. Moreover the dot product could be regarded like the other operations. Whether it (as an interval operation, i.e. an interval extension of the point function) should be required or not, I don't know. If it is specified, how about also specifying the sum of n terms (which is a particular case of the dot product)? -- Karlsruher Institut für Technologie (KIT) Institut für Angewandte und Numerische Mathematik (IANM2) D-76128 Karlsruhe, Germany Prof. Ulrich Kulisch Telefon: +49 721 608-42680 Fax: +49 721 608-46679 E-Mail: ulrich.kulisch@xxxxxxx www.kit.edu www.math.kit.edu/ianm2/~kulisch/ KIT - Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft |
Attachment:
Poster22.pdf
Description: Adobe PDF document