bin/170206: complex arcsinh, log, etc.

Bruce Evans brde at optusnet.com.au
Fri Jul 27 14:27:05 UTC 2012


On Wed, 25 Jul 2012, Stephen Montgomery-Smith wrote:

> This function seems to be able to compute clog with a worst case relative 
> error of 4 or 5 ULP.
> ...

I lost your previous reply about this after reading just the first part.
Please resend if interested.

First part recovered by vidcontrol:

VC> > I'm still working on testing and fixing clog.  Haven't got near the more
VC> > complex functions.
VC> >
VC> > For clog, the worst case that I've found so far has x^2+y^2-1 ~= 1e-47:
VC> >
VC> >      x = 0.999999999999999555910790149937383830547332763671875000000000
VC> >      y =
VC> > 0.0000000298023223876953091912775497878893005143652317201485857367516
VC> >        (need high precision decimal or these rounded to 53 bits binary)
VC> >      x^2+y^2-1 = 1.0947644252537633366591637369e-47
VC> 
VC> That is exactly 2^(-156).  So maybe triple quad precision really is enough.

Hmm.  But you need 53 more value bits after the 156.  Quadruple precision
gives 3 to spare.  I didn't notice that this number was exactly a power
of 2, but just added 15-17 for the value bits in decimal to 47 to get over
60.

VC> > so it needs more than tripled double precision for a brute force
VC> > evaluation, and the general case is probably worse.  I'm working
VC> > on a rearrangement so that doubled double precision works in the
VC> > general case.  Both your version and my version get this case right,
VC> > but mess up different much easier cases.  It takes insanely great
VC> > accuracy to get even 1 bit in this case right, but now that we

Tripled double precision is enough for this because -1 cancels with
leading terms, giving almost quadrupled double precision:

% 	hm1 = -1;
% 	for (i=0;i<12;i++) hm1 += val[i];
% 	return (cpack(0.5 * log1p(hm1), atan2(y, x)));

It is the trailing terms that I think don't work right here.  You sort
them and add from high to low, but normally it is necessary to add
from low to high (consider terms [1, DBL_EPSILON/2, DBL_EPSILON/4]).
Adding from high to low cancels with the -1 term, but then only
particular values work right.  Also, I don't see how adding the low
terms without extra precision preserves enough precision.

Bruce


More information about the freebsd-bugs mailing list