cpow and clog
sgk at troutmask.apl.washington.edu
Tue Nov 7 15:31:50 UTC 2017
On Tue, Nov 07, 2017 at 10:38:59AM +0000, dimpase at gmail.com wrote:
> On Mon, Nov 06, 2017 at 12:41:21PM -0800, Steve Kargl wrote:
> > On Mon, Nov 06, 2017 at 08:49:43PM +0100, Michael Danilov wrote:
> > > I would like to have some feedback on my attempt to import OpenBSD
> > > code for cpow and clog:
> > >
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221341
> > > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=187693
> > >
> > > What happened to the alternative implementation mentioned in the thread below?
> > bde has an implementation of clog[fl]. He may someday
> > commit it. I don't know if anyone ever worked on cpow[fl].
> > I stopped working on powl and tgammal when I returned my
> > commit bit due to differences with "higher-ranking" committers.
> > > And what had stopped the developers from just reusing the Net-i
> > > or OpenBSD code?
> > How have you tested the NetBSD and/or OpenBSD code? What is the
> > quality? Have the long double clogl and cpowl been tested on both
> > ld80 and ld128 hardware? See FreeBSD's lib/msun/src/math_private.h
> > for a discussion of possible issues of using I from complex.h in this
> > code.
> I would like to point out that various FreeBSD ports already contain
> implementations of the functions in question.
What is the quality of those implementations? Have you tested the
code? Have you read the comment in math_private.h concerning the
use of I in computations?
> Sorry for being blunt, but IMHO the attitude on this list appears to be
> to let the numerics stack on FreeBSD die a slow death.
You're talking to the one person who has spent decades trying to
improve libm through bug fixes and implementing missing functionality.
> Indeed, most people hate to reinvent the wheel. It's
> really no fun at all to scramble to get these missing implementations
> somehow, there are certainly much better ways to use one's time and
> brainpower. On this list people prefer to point at some private code in
> uncertain shape, and hope that somehow by some magic FreeBSD will have
> the best humanely possible implementation of the complex transcendental
On this list, which is mostly Bruce and me it seems, people care about
the quality of the code. People, which is mostly Bruce and me, spend
quite a bit of time benchmarking proposed patches go ensure that users
aren't fed wrong results.
> Why don't you first of all try to provide *some* reasonably
> working implementation (thus allowing porters not to have to reinvent
> this wheel, badly, for $n$-th time over, and then having *fun* making
> sure the tools know where to get these functions), and only then try to
> improve it?
Who is 'you' here? I recently provided implementations of sinpi[fl], cospi[fl],
and tanpi[fl] for ISO/IEC TS 18661-4. Patches were submitted to this list
(check the archive). Bruce is the only person to comment on the patch. I took
the time to fix the lang/python* ports, which break with this patch, and sent
the patches to freebsd-ports list where the patches are lost in time.
Check out the history of msun/src/imprecise.c. This is a 'workaround'
committed by David Chisnall so that FreeBSD could claim C++ conformance.
David has never lifted a finger to fix that kludge. I am the person
who has clean up that mess (until I stopped working on powl and tgammal).
This is exactly the the situation that people on this list are trying to
avoid when someone wants to simply "provide *some* reasonably working
Instead of complaining about the people on this list, which is mostly
Bruce and me, why not help. So, I'll repeat myself here. What is the
quality of those implementations? Have you tested the code? Have you
read the comment in math_private.h concerning the use of I in computations?
More information about the freebsd-numerics