Date: Tue, 28 May 2013 15:53:10 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-numerics@freebsd.org Subject: Re: Patches for s_expl.c Message-ID: <20130528225310.GA53144@troutmask.apl.washington.edu> In-Reply-To: <20130529062437.V4648@besplex.bde.org> References: <20130528172242.GA51485@troutmask.apl.washington.edu> <20130529062437.V4648@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 29, 2013 at 07:39:04AM +1000, Bruce Evans wrote: > On Tue, 28 May 2013, Steve Kargl wrote: > > > Here are two patches for ld80/s_expl.c and ld128/s_expl.c. > > Instead of committing the one large patch that I have spent > > hours testing, I have split it into two. One patch fixes/updates > > expl(). The other patch is the implementation of expm1l(). > > > > My commit messages will be: > > > > Patch 1: > > > > ld80/s_expl.c: > > > > * Use the LOG2_INTERVALS macro instead of hardcoding 7. > > The use of LOG2_INTERVALS isn't merged into the ld128 version. Patch 2 > merges its use for expm1l() only. > > > * Use LD80C to set overflow and underflow thresholds, and then use > > #defines to access the .e component to reduce diffs with ld128 version. > > * Rename polynomial coefficients P# to A#, which is used in Tang. > > Almost all the declarations polynomial coefficients are still formatted > in a nonstandard way, but differently than in previous development > versions. I keep sending you patches for this. Given that I've merged, unmerged, remerged, disremerged, and undisremerged numerous diffs over the last 2+ years, I am not surprise that there are issues with the patches. I'm neither an expert in floating arithmetic nor style(9). If I understand half of what you write when you annotate one of your diffs, I feel lucky. (Un)fortunately, I only have a few hours this week to work on expl/expm1l, and then I'll disappear again for a month or two (due to work and life). (Un)fortunately, theraven (under the pretense of core) has threaten to completely rendered libm into a crippled useless mess by mapping all unimplemented long double functions to their double cousins. When/if it comes to pass that I have to untangle whatever theraven does, I'll likely just walk away from libm hacking. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130528225310.GA53144>