Date: Mon, 10 Dec 2007 21:16:27 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David Schultz <das@FreeBSD.ORG> Cc: freebsd-standards@FreeBSD.ORG, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: Implementation of expl() Message-ID: <20071210200058.Y30409@besplex.bde.org> In-Reply-To: <20071210071650.GA12886@VARK.MIT.EDU> References: <20071103001305.GA82775@troutmask.apl.washington.edu> <20071209212505.GA9698@VARK.MIT.EDU> <20071209213450.GA95726@troutmask.apl.washington.edu> <20071209223918.GA9920@VARK.MIT.EDU> <20071210153413.W3836@delplex.bde.org> <20071210071650.GA12886@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Dec 2007, David Schultz wrote: > On Mon, Dec 10, 2007, Bruce Evans wrote: >> Better algorithms exist, like someone named das@ used for exp2(), but >> would be harder to debug and maintain. > > I'm not worried about maintenance, since I don't expect God to add > any major new features to e^x any time soon. But every different precision requires a significantly different implementation (mainly for magic number, but table-driven methods give a huge number of those) since we don't have algorithms or tools to generate all the magic numbers from the precision parameter. > Writing exp2() took a > lot of reading papers and tinkering, and it's a pain in the neck > to generate the constants and figure out the resulting error for > each interval. I seem to recall trying the same tricks for expl(), > but there were problems with rescaling in base e instead of base 2 > without losing accuracy. In any case, I don't have the kind of time > needed to fix all of that stuff now. The problems are well understood :-). I didn't understand them when you started working on exp2() but do now. Essentially, they are due to the strange phenomenon that linear functions are usually harder to approximate (to within 1 ULP) than transcendental functions expanded in a Taylor series about 0. The linear scaling step with a not-exactly representable factor like log2(e) ends up being the most difficult point (unless it is done inaccurately). > I don't really care how expl() is implemented; anything that works > is better than anything that doesn't. If someone comes up with a > better, cleverer scheme later, that's great, but we've been > talking about a lot of this stuff forever and there's still > nothing in the tree. I only agree if "working" includes no new bugs and good accuracy at little cost. We still don't support 64-bit precision on i386. Fixing that has higher priority. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071210200058.Y30409>