This is the mail archive of the
`glibc-bugs@sourceware.org`
mailing list for the glibc project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla at sourceware dot org>*To*: glibc-bugs at sources dot redhat dot com*Date*: Mon, 05 Mar 2012 13:32:24 +0000*Subject*: [Bug math/3976] libm rounding modes do not work correctly for many archs*Auto-submitted*: auto-generated*References*: <bug-3976-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=3976 --- Comment #16 from Vincent LefÃvre <vincent-srcware at vinc17 dot net> 2012-03-05 13:32:24 UTC --- (In reply to comment #10) > (In reply to comment #9) > > I would say that each function probably has the same problem. > > Actually log and atan seem to behave correctly (and even honor the rounding > mode). I forgot that since Ziv's strategy is used to provide correct rounding, my tests where incomplete (I tested only on a few random values). To understand the problem, here's what Ziv's strategy does: 1. Compute an approximation with slightly more precision than the target precision, typically by representing it as an exact sum of two floating-point values a+b, where |b| is much smaller than |a|. An error bound e1 is determined and a rounding test is performed. Most of the time, the correct rounding can be guaranteed by this test, so that the computed result can be returned. But there's a low probability of failure (problem known as the "Table Maker's Dilemma"), in which case a second step is necessary. 2. Ditto with even more precision and a lower error bound e2. In case of failure, a third step is necessary. 3. Computation with even more precision. IIRC, a 768-bit precision is used here in IBM's library (that's the mp*.c files), which assumes that this is sufficient. So, for functions that are believed to behave correctly in the directed rounding modes, and for which the active rounding mode is not changed temporarily in the function, one should consider the following remarks: One would need to test cases that fall in (2) and in (3). The probabilities of failure depend on the algorithm and implied error bounds e1 and e2, and possibly on the magnitude of the input (or some other criteria). To get cases in (2) from random tests, one may need to test several dozens of thousands of inputs (analyzing the code can give a better idea of what is needed -- it doesn't seem to be much documented). Ideally, tools like gcov to get code coverage would be useful. From my work on the Table Maker's Dilemma, I also have a list of the hardest-to-round cases ("worst cases") for some functions in some domains, which should probably fall in (3). AFAIK, in IBM's library, (3) uses integer arithmetic, so that it shouldn't depend on the active rounding mode (though I'm not completely sure because FP may also be used, e.g. at the end). Note that testing cases for (3) only is not sufficient, because with such cases, the results from (2) are discarded. It is also possible that in directed rounding modes, (1) and/or (2) always fail, meaning that a slower step would be performed. This wouldn't be incorrect, but rather inefficient. This should be checked too... -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |