Bug 216864
| Summary: | cpow(), cpowf(), and cpowl() need better implementations | ||
|---|---|---|---|
| Product: | Base System | Reporter: | sgk |
| Component: | standards | Assignee: | freebsd-numerics (Nobody) <numerics> |
| Status: | Open --- | ||
| Severity: | Affects Many People | CC: | avos, emaste, kargl |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
Fixed in base r336299 (In reply to Andriy Voskoboinyk from comment #1) The import of functions from Cephes is a KLUDGE. I suspect that no one actually tested the code that was committed. In particular, all of the long double code on i686 class hardware likely have at least a 2^11 ULP error. At one time, FreeBSD commtter prided themselves for code quality. Not so much now days. (In reply to Steve Kargl from comment #2) Patches for better quality implementations of these are most welcome. Ed wrote:
> Patches for better quality implementations of
> these are most welcome.
Not sure if you're being cheeky or not.
I'm still trying to fix the kludge perpetrated
by theraven@ with his imprecise.c mess. There's
only 2 functions left from that fiasco (powl and
tgammal). I fixed erfl, erfcl, lgammal, lgammal_r,
coshl, sinhl, and tanhl. Getting the details correct
(at least for me) isn't easy.
r336299 committed code from Cephes for powl, which
now papers over theraven@'s original kludge for powl.
So, we went from bad to possibly worse.
Drive-by commits where the committer has no intention
of actually fixing libm, let alone testing, is a
major disincentive to continue to work on libm.
Finally, libm isn't C99 compliant because ccoshl,
ccosl, cexpl, csinhl, csinl, ctanhl, and ctanl are all
missing. I spent part of the last two weeks working
on ccoshl, ccosl, and cexpl, and had planned to work
on csinhl and csinl this weekend.
Retitle and reopen (the previous one causes too much confusion). (In reply to Steve Kargl from comment #4) Sorry for the snarkiness of my comment, I did not intend it to be so. Either way the intent is genuine - I really do want to see proper implementations in libm rather than hacks that paper over issues. To that end, what do you think about: a. adding comments to those files referencing this PR (or a similar PR for other functions) and pointing out that a proper implementation is required b. adding a link-time warning (as emitted if using e.g. gets) that the current implementation is poor quality Is this an accurate view of the current status: Some sort of work in progress: ccoshl ccosl cexpl csinhl csinl Improved implementations needed: cpow cpowf cpowl powl tgammal No current implementation: ctanhl ctanl (In reply to Ed Maste from comment #6) > a. adding comments to those files referencing this PR (or > a similar PR for other functions) and pointing out that a > proper implementation is required It can't hurt, but I suspect that I'm the only person besides bde that looks at the implementation details of the various libm functions. > b. adding a link-time warning (as emitted if using e.g. > gets) that the current implementation is poor quality To theraven@'s credit, he does have a link-time and/or run-time warning in imprecise.c. his code is /* * If long double is not the same size as double, then these will lose * precision and we should emit a warning whenever something links against * them. */ #if (LDBL_MANT_DIG > 53) #define WARN_IMPRECISE(x) \ __warn_references(x, # x " has lower than advertised precision"); #else #define WARN_IMPRECISE(x) #endif The message can probably be audited to state __warn_references(x, # x " needs a code review and tested"); and added to cpow[fl] and powl code. > Is this an accurate view of the current status: > > Some sort of work in progress: ccoshl ccosl cexpl csinhl csinl > Improved implementations needed: cpow cpowf cpowl powl tgammal > No current implementation: ctanhl ctanl ccoshl, ccosl, and cexpl are implemented. I need to do more testing, and the code needs review. I post codes to freebsd-numerics@ and bde normal does a review. At the moment, I have the feeling that I am the only subscriber to that list. csinhl and csinl will be implemented this week. Review and testing will follow. I haven't looked at ctanh and ctan, so don't know the difficulty in porting those to ld80 and ld128. tgammal is mapped by imprecises.c to tgamma, so at most 53-bit precision. cpow[fl] and powl use Cephes. These could use review and testing. I suspect that bde will not look at this code, and I probably will just work new implementations. |
#include <complex.h> double complex foo(double complex a, double complex b) { return (cpow(a, b)); } float complex foof(float complex a, float complex b) { return (cpowf(a, b)); } long double complex fool(long double complex a, long double complex b) { return (cpowl(a, b)); } cc -c foo.c foo.c:7:12: warning: implicitly declaring library function 'cpow' with type '_Complex double (_Complex double, _Complex double)' [-Wimplicit-function-declaration] return (cpow(a, b)); ^ foo.c:7:12: note: include the header <complex.h> or explicitly provide a declaration for 'cpow' foo.c:12:12: warning: implicitly declaring library function 'cpowf' with type '_Complex float (_Complex float, _Complex float)' [-Wimplicit-function-declaration] return (cpowf(a, b)); ^ foo.c:12:12: note: include the header <complex.h> or explicitly provide a declaration for 'cpowf' foo.c:18:12: warning: implicitly declaring library function 'cpowl' with type '_Complex long double (_Complex long double, _Complex long double)' [-Wimplicit-function-declaration] return (cpowl(a, b)); ^ foo.c:18:12: note: include the header <complex.h> or explicitly provide a declaration for 'cpowl' 3 warnings generated.