Skip site navigation (1)Skip section navigation (2)
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>