Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Aug 2012 23:03:46 -0000
From:      Stephen Montgomery-Smith <stephen@missouri.edu>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Diane Bruce <db@db.net>, John Baldwin <jhb@freebsd.org>, David Chisnall <theraven@freebsd.org>, Bruce Evans <bde@freebsd.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>, David Schultz <das@freebsd.org>, Peter Jeremy <peter@rulingia.com>, Warner Losh <imp@bsdimp.com>
Subject:   Re: Use of C99 extra long double math functions after r236148
Message-ID:  <501295C9.6080108@missouri.edu>
Resent-Message-ID: <20120812230340.GJ20453@server.rulingia.com>
In-Reply-To: <20120727155521.E4712@besplex.bde.org>
References:  <20120717042125.GF66913@server.rulingia.com> <20120717043848.GB87001@troutmask.apl.washington.edu> <20120717225328.GA86902@server.rulingia.com> <20120717232740.GA95026@troutmask.apl.washington.edu> <20120718001337.GA87817@server.rulingia.com> <20120718123627.D1575@besplex.bde.org> <20120722121219.GC73662@server.rulingia.com> <500DAD41.5030104@missouri.edu> <20120724113214.G934@besplex.bde.org> <501204AD.30605@missouri.edu> <20120727032611.GB25690@server.rulingia.com> <20120727155521.E4712@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 07/27/12 02:27, Bruce Evans wrote:
> On Fri, 27 Jul 2012, Peter Jeremy wrote:
>
>> On 2012-Jul-26 22:02:05 -0500, Stephen Montgomery-Smith
>> <stephen@missouri.edu> wrote:
>>> I am not getting many responses to the programs I submitted.  I
>>> understand that you may be all very busy.
>
> I'm still working on testing and fixing clog.  Haven't got near the more
> complex functions.
>
> For clog, the worst case that I've found so far has x^2+y^2-1 ~= 1e-47:
>
>      x = 0.999999999999999555910790149937383830547332763671875000000000
>      y =
> 0.0000000298023223876953091912775497878893005143652317201485857367516
>        (need high precision decimal or these rounded to 53 bits binary)
>      x^2+y^2-1 = 1.0947644252537633366591637369e-47

That is exactly 2^(-156).  So maybe triple quad precision really is enough.

>
> so it needs more than tripled double precision for a brute force
> evaluation, and the general case is probably worse.  I'm working
> on a rearrangement so that doubled double precision works in the
> general case.  Both your version and my version get this case right,
> but mess up different much easier cases.  It takes insanely great
> accuracy to get even 1 bit in this case right, but now that we
> have about 52 of 53 right, the work for getting the final bit
> right is essentially the same as proving that the method works
> in all cases.  That's for x^2+y^2-1.  log1p() is much harder.

The general case is also the worst for the arc-trig functions.  The edge 
cases seem to be computed with great accuracy.

When I tell my friends I get approx 51 bit accuracy, they seem to think 
it is pretty good.


>
>> I've been writing a test harness to vet the special case handling of
>> all the complex functions (excluding cpow so far).  Basically, it's

If I remember correctly, the C99 specification is very liberal in its 
requirements for cpow, so that
cpow(x,y) = cexp(y*clog(x))
is compliant.

>
> I use a my test harness for float and double functions hacked for
> complex functions where it doesn't work so well, and hackish pari
> extensions.
>
>> just Appendix G.6 of WG14/N1256 turned into a C array, plus code to
>> actually run the tests & interpret the results.  So far, it's about
>> 1100 lines of which about 1/3 is the test cases and is intended to run
>
> Yikes.  My basic test program is getting too large and complex at 412
> lines.  It basically just compares with a known good or different bad
> function (with zillions of parameters to select the function and args).
> It tests exceptional cases as a side effect.
>
> Do you do tests for fenv (i.e, that the specified exceptions and no
> others are raised)?  This might be a problem with external libraries.
> The can deliver values and NaNs for comparison, but nothing requires
> them to have the same fenv behaviour as the C library.  Any tests
> of fenv are likely to spew errors that you don't want to know about.

Testing the fenv values seems like a really good idea to me.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?501295C9.6080108>