Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Reduction operations in P1788/D9.5

Am 11.01.2015 um 14:51 schrieb John Pryce:

On 11 Jan 2015, at 09:25, Oliver Heimlich <oliver@xxxxxxxxxxxxxxxxxxx> wrote:

Am 11.01.2015 um 08:17 schrieb John Pryce:
[...]

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])...


I find this a strong, but not clinching argument. As I recall -- though I haven't re-studied the lengthy debates on the relevant motions -- several knowledgeable people in P1788 had the view that reduction operations (ROs) for interval vectors were not very useful, and this is why we left them out. (I sent a separate email to Siegfried Rump about this, as he is one of the "knowledgeable people".)

Namely, (I think the argument was) one uses ROs most effectively not as interval ROs, but as point ROs with directed rounding, within an interval algorithm. If so, that makes them part of the Level 3 toolkit for writing Level 2 operations. Maybe they should be moved to Clause 14?

Knowledgeable people, please comment.
Ah, slowly this seems to make some sense. I have missed the debate back then, because I had been quite occupied.
For example, in an interval dot function you could make an distinction of 10 cases for pairs of interval boundaries and apply the point ROs for 10 subsets of interval boundaries. Then, sum the 10 numbers up and you get one interval boundary of the final result. Repeat this process for the other boundary of the result. 

However, I see the following drawbacks in the example:
- You must encode empty interval boundaries with NaN. The standard allows different encodings. - You still have to deal with 10 intermediate results in finite precision, so you lose the benefit of correctly rounded boundaries.
If the underlying IEEE 754 system supports the mentioned ROs, you can simply build (for example) an interval dot function with "valid" accuracy (the optional operations from 12.13.5 allow for tightest accuracy).
On the other side, if the underlying IEEE 754 system does not support the mentioned ROs, a IEEE P1788 conforming implementation must provide the ROs, which I find cumbersome for upcoming implementations of the interval arithmetic standard.
The ROs are optional in IEEE 754-2008 and their accuracy may be "implementation-defined".