Bug 216864 - cpow(), cpowf(), and cpowl() need better implementations
Summary: cpow(), cpowf(), and cpowl() need better implementations
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-standards mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-06 19:50 UTC by sgk
Modified: 2019-02-09 00:09 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sgk 2017-02-06 19:50:26 UTC
#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.
Comment 1 Andriy Voskoboinyk freebsd_committer 2019-02-07 20:43:55 UTC
Fixed in base r336299
Comment 2 Steve Kargl freebsd_committer 2019-02-07 21:16:18 UTC
(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.
Comment 3 Ed Maste freebsd_committer 2019-02-07 21:28:32 UTC
(In reply to Steve Kargl from comment #2)
Patches for better quality implementations of these are most welcome.
Comment 4 Steve Kargl freebsd_committer 2019-02-07 22:18:04 UTC
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.
Comment 5 Andriy Voskoboinyk freebsd_committer 2019-02-07 22:22:11 UTC
Retitle and reopen (the previous one causes too much confusion).
Comment 6 Ed Maste freebsd_committer 2019-02-08 22:27:27 UTC
(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
Comment 7 Steve Kargl freebsd_committer 2019-02-09 00:09:37 UTC
(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.