Patches for s_expl.c

Steve Kargl sgk at troutmask.apl.washington.edu
Wed May 29 00:06:23 UTC 2013


On Tue, May 28, 2013 at 06:17:46PM -0500, Stephen Montgomery-Smith wrote:
> On 05/28/2013 05:53 PM, Steve Kargl wrote:
> 
> > 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.
> 
> I think it is better to commit "as is" if you cannot make all the changes.
> 
> As for me, I don't really understand the need to be so consistent with
> style, nor to get every last drop of optimization.  In particular,
> regarding style, I think it is like people talking different languages.
>  You could insist that everyone speak a common language, but it is far
> better for the intellectual commons if people learn other peoples'
> languages.
> 
> Anyway, I think it is better for Steve to commit, and then for Bruce to
> make changes later on.
> 

It's too late.  In making some change since the last time I test
has introduced a massive regression in the computation of expm1l.

laptop-kargl:kargl[204] ./testl -n 5 -b
prec: 64
For x in [-64.0000:-0.1659], 5M expm1l calls in 2.176513 seconds.
For x in [-0.1659:0.1659], 5M expm1l calls in 0.415051 seconds.
For x in [0.1659:11356.0000], 5M expm1l calls in 0.550342 seconds.

Notice, the first interval is now 4 to 5 times slower than the
other intervals.  This was not the case with an older version
of the code.

:(


-- 
Steve


More information about the freebsd-numerics mailing list