From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:01:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8D28106564A for ; Mon, 9 Jul 2012 02:01:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE398FC08 for ; Mon, 9 Jul 2012 02:01:08 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q69217Ku054020; Sun, 8 Jul 2012 19:01:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q69217tv054019; Sun, 8 Jul 2012 19:01:07 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 19:01:07 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120709020107.GA53977@troutmask.apl.washington.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFA25EA.5090705@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:01:08 -0000 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