Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Jan 2012 14:34:24 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: libm

On Fri, Jan 27, 2012 at 08:01:18PM +0100, Pascal Cuoq wrote:
> On Fri, Jan 27, 2012 at 5:02 PM, Szabolcs Nagy <nsz@...t70.net> wrote:
> 
> > meanwhile i compared some implementations
> > openbsd, freebsd and glibc are worth to look at
> >
> 
> Sorry to intrude in your conversation, but for reasons of
> my own I was recently looking for an aesthetically pleasing
> single-precision implementation of trigonometric functions,
> and some of the single-precisions functions out there are
> so ugly that I would seriously consider implementing
> these in musl by a call to their respective double-precision
> counterparts, despite the disadvantages. At least it's compact.

*Nod*, this is the way I'm leaning for single-precision anyway. The
only possible reason to reconsider is that some systems (i.e. some
ARMs) have slow software emulation of double precision but native
single precision, or so I'm told...

> Consider:
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libm/src/k_cosf.c?rev=1.3;content-type=text%2Fplain
> 
> The code written at Sun and that many libms reuse must
> have been double-precision only, and someone had to
> make a single-precision version of them at some point.
> Without the analysis that led to the original code, one
> cannot blame Ian Lance Taylor for staying close
> to the double-precision function:
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libm/src/k_cos.c?rev=1.4;content-type=text%2Fplain
> 
> But the degree of the polynomial in the single-precision version
> is about twice what is necessary, and the coefficients
> look like coefficients of the Taylor expansion rounded to
> nearest float, when they should be Chebyshev coefficients.

Agreed, this is ridiculous.

> Criticism is easy and art is difficult. I don't know how
> to write a better single-precision function, I just know
> that this one, for instance, cannot be good.

Well I think it's fair to judge when they could have just wrapped the
double precision versions. Granted this can result in 1ulp error, but
it's not a big deal and within the tolerances required by the
standard...and if their implementations of the single-precision
versions are as bad as you say, I can't imagine they're always
correctly rounded anyway..

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.