The standard http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf specifies them in the section "7.3.8.2 The cpow functions": > #include <complex.h> > double complex cpow(double complex x, double complex y); > float complex cpowf(float complex x, float complex y); > long double complex cpowl(long double complex x, > long double complex y); Similarly, the section "G.6.3.2 The clog functions" specifies clog. > double complex clog(double complex z); > float complex clogf(float complex z); > long double complex clogl(long double complex z); They are entirely missing.
What exactly is the status of these missing functions? I understand that there were candidate implementations, but they were rejected on the basis of insufficient quality. Is it acceptable to provide an implementation relying on an extended or an arbitrary precision library? If so, what are the license requirements? Would LGPL be possible? Our interest is in resurrecting an old FreeBSD port of sagemath: https://trac.sagemath.org/query?component=porting%3A+BSD The fact that one needs to rely on a supplementary libm with the missing implementations does not make it easier...
I second that. Keeps me from porting this one: https://github.com/NFFT/nfft Just did a quick search, other BSDs have had them for years! https://github.com/IIJ-NetBSD/netbsd-src/blob/master/lib/libm/complex https://github.com/openbsd/src/blob/master/lib/libm/src So I copied those from OpenBSD. Not sure I did everything right -- could someone with experience please have a look? For example, I'm not sure what Symbol.map does -- and whether the order of that list matters, so I just added those things to the end. Was able to buildworld & compile NFFT with those, but I can not tell whether it works. By the way, is there any way to build _just one_ library without having to wait for the whole buildworld? It takes too long even if I run it with ccache and keeping the old /usr/obj.
Created attachment 187692 [details] Patch for 11-RELEASE-p2
Created attachment 187693 [details] Patch for 11-RELEASE-p2 Ah, geez, think I get it with the Symbols.map.
There are some old discussions of cpow etc on freebsd-numerics, e.g. https://lists.freebsd.org/pipermail/freebsd-numerics/2012-August/000027.html It looks as if the preferred by the maintainers option was that it's better to have no implementation than a low-precision one. Perhaps it makes sense to post there a link to this patch, and ask whether it would be accepted.
(In reply to Dima Pasechnik from comment #1) Hi, I found out how to get around this: copy over the respective function from either NetBSD or OpenBSD and change the Makefiles to compile it in. Examples: comms/xnec2c and math/nfft (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223429)
(In reply to Michael Danilov from comment #6) This is perpetuating the bloat. Surely, one can keep having these functions in patches, but this is ludicrous. Why not poking https://wiki.freebsd.org/Numerics people?
I will. But here and now we just need things to work, and also I was told that it won't make it to older versions, so the workaround will have to be there anyway: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223429#c3
(In reply to Michael Danilov from comment #8) Is there any reason to care for older versions?
Long as they are still maintained, I believe. One can always set "BROKEN" for them, ofc.
(In reply to Yuri Victorovich from comment #0) > Similarly, the section "G.6.3.2 The clog functions" specifies clog. > >> double complex clog(double complex z); >> float complex clogf(float complex z); >> long double complex clogl(long double complex z); > > They are entirely missing. A patch for the above has been sitting in bugzilla since 2-17-2017. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216863 Don't expect progress on any other math functions. No one cares (except me).
It seems like the missing functions have been committed in r333577 and more recently r336299. *** This bug has been marked as a duplicate of bug 175811 ***