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]

[Bug math/3976] libm rounding modes do not work correctly for many archs


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]