cpow and clog

Tue Nov 7 17:54:01 UTC 2017

On Tue, Nov 07, 2017 at 07:31:49AM -0800, Steve Kargl wrote:
> 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?
Do you have a testsuite for these functions? Perhaps it can be found
somewhere, do you know?
We are able to make bits of code needed for conformance to pass our tests in Sagemath
on FreeBSD 11 (x86_64 only, although I probably can get FreeBSD running
on aarch64 somehow) with various clang versions, and with gcc6. 
Basically I am talking about these functions from the Cephes library:
http://files.sagemath.org/spkg/upstream/cephes/index.html

> Have you read the comment in math_private.h concerning the
> use of I in computations?
I presume you refer to

"...x+I*y is
 * currently unusable in general since gcc introduces many overflow,
 * underflow, sign and efficiency bugs..."

We are building FreeBSD with clang, and not gcc, I don't know how
relevant it is, for clang is a fast-moving target.
By the way, https://wiki.freebsd.org/Numerics still mentiones FreeBSD 10
as "current"...

> 
> > 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
> > functions... 
> 
> 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).  

Well, this involves browsing entries of https://lists.freebsd.org/pipermail/freebsd-numerics/
Would you mind at least mention year and month?

> 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.

Nowadays one would rather expect a git branch with the changes, not
patches, as you might know.

> 
> 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
> implementation".
See, it was great work, it has allowed him to publish stuff, e.g.:
http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201403-asiabsdcon2014-llvmbsd.pdf
:-)

His homepage however says that he's "Former Core Team member" of FreeBSD.
If https://wiki.freebsd.org/Numerics is the right place to look at, this
issue ought to be mentioned there, don't you think so?

> 
> 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?

While I do have some time to spend on this in the coming year or so, I
would like to understand how the developent process works in this
particular case, who have rights to commit changes, how tests are run,
whether there is any CI system to be used, etc.
It seems that one has to start by setting up a set of tests for these
functions.

Dima

> 
> -- 
> Steve