Date: Sun, 8 Jul 2012 19:01:07 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Stephen Montgomery-Smith <stephen@missouri.edu> Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 Message-ID: <20120709020107.GA53977@troutmask.apl.washington.edu> In-Reply-To: <4FFA25EA.5090705@missouri.edu> References: <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 08, 2012 at 07:29:30PM -0500, Stephen Montgomery-Smith wrote: > On 07/08/2012 06:58 PM, Steve Kargl wrote: > >On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: > > >>So do people really work hard to get that last drop of ulp out of their > >>calculations? > > > >I know very few scientist who work hard to reduce the ULP. Most > >have little understanding of floating point. > > > >> Would a ulp=10 be considered unacceptable? > > > >Yes, it is unacceptable for the math library. Remember ULPs > >propagate and can quickly grow if the initial ulp for a > >result is large. > > OK. But suppose I wanted ld80 precision. What would be the advantage > of using an ld80 expl function with a ulp of 1 over an ld128 expl > function with a ulp of 10? The error propagation in the latter case > could not be worse than the error propagation in the latter case. Well, on the most popular hardware (that being i386/amd64), ld80 will use hardware fp instruction while ld128 must be done completely in software. The speed difference is significant. > In other words, if I were asked to write a super-fantastic expl > function, where run time was not a problem, I would use mpfr, use > Taylor's series with a floating point precision that had way more digits > than I needed, and then just truncate away the last digits when > returning the answer. And this would be guaranteed to give the correct > answer to just above 0.5 ulp (which I assume is best possible). It's more like 1 ULP after truncation (, which isn't truncation but rounding). The problem is run-time that 'run-time is the problem'. Try writing a expl() and simply use mpfr_exp() with 64-bit precision. If you're doing any serious simulation where exp() will be evaluate millions or billions of time, you'll notice the difference. > The only way I can see ULP errors greatly propagating is if one is > performing iteration type calculations (like f(f(f(f(x))))). Have you read Goldberg's paper? Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120709020107.GA53977>