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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
