| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Am 11.01.2015 um 08:17 schrieb John Pryce:
754 is fairly clear on what NaN *does* -- the Level 2. (Actually it's vague on the Level 2 of NaN payloads.) It is vague on what NaN *is* -- the Level 1. Of several views of NaN at Level 1, two are A. NaN is the result of a previous error. B. NaN stands for an unknown number, finite or infinite. I think Hossam is taking view A, while the 754definition of reduction operations is based on view B. (One must also consider, as Siegfried Rump has often pointed out, that Inf also has two meanings: genuine infinity, and a number whose FP approximation became too large to represent as finite.)
[...]
The precedence rule for sumAbs, implied by this Level 1 meaning, would then be If an sNaN is encountered, sNaN shall be returned. Otherwise, if an Infinity is encountered, +oo shall be returned. Otherwise, if a qNaN is encountered, qNaN shall be returned. I guess this affects dot and sum also, and maybe the "All other behavior" on p63 line 27. Michel, and others expert in low-level aspects, can say if this fits well with the 754-defined behaviour of sNaN and qNaN, and if it can implemented efficiently enough that the extra clarity outweighs the cost.
I have already stated in the comments of the ballot [1] that I believe the current definition of the reduction operations does not quite fit to the rest of the standard, especially a set-based interval arithmetic.
You explain how NaNs should be interpreted and that they could possibly stand for unknown numbers. Nowhere else in the standard NaNs are used (except for a possible choice of encoding [Empty]). The interval [Entire] perfectly represents an unknown number. An error that should propagate through computation can be achieved with decorated intervals and [NaI]s.
IMHO the reduction operations should better be defined on arrays/lists of intervals. Then above questions would simply not arise and the standard would be consistent, because it would solely define interval arithmetic operations with consistent behaviour.
Best regards Oliver Heimlich[1] For those of you who are not in the ballot group, here is a copy of my comment:
The reduction operations are very important -- especially the dot operation. The standard's support for these functions is weak: (1) The standard does not mention dot, sum, ... operations for interval vectors. Interval vectors are only mentioned for level 1. Input and output of interval vectors is not described. (2) The required reduction operations in 12.12.12 do not match the rest of the chapter. The described behaviours for NaNs and infinite numbers match IEEE 754-2008, but are of no use for a set-based interval arithmetic. (3) The operations described in 12.13.5 can be used to implement reduction operations on interval vectors. However, they should not be public operations, because they operate on an accumulator format and not on intervals (in contrast to other operations described by the standard).
In their current wording the sections 12.12.12 and 12.13.5 would rather fit a new revision of IEEE 754, because they concern IEEE 754 operations and data types but no intervals.
Proposed Change:I suggest to improve both sections: Require to implement reduction operations dot, sum, sumAbs, and sumSquare for intervals on level 2 with tightest accuracy. A 754-conforming implementation could then be recommended to use the accumulator operations currently described by 12.13.5.