Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Jul 2012 11:51:56 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        David Schultz <das@freebsd.org>
Cc:        freebsd-current@FreeBSD.ORG, Peter Jeremy <peter@rulingia.com>, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: Use of C99 extra long double math functions after r236148
Message-ID:  <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com>
In-Reply-To: <20120708124047.GA44061@zim.MIT.EDU>
References:  <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jul 8, 2012, at 6:40 AM, David Schultz wrote:

> On Tue, May 29, 2012, Peter Jeremy wrote:
>> On 2012-May-28 15:54:06 -0700, Steve Kargl =
<sgk@troutmask.apl.washington.edu> wrote:
>>> Given that cephes was written years before C99 was even
>>> conceived, I suspect all functions are sub-standard.
>>=20
>> Well, most of cephes was written before C99.  The C99 parts of
>> cephes were written to turn it into a complete C99 implementation.
>=20
> I'm a bit late to the party, but I thought I'd chime in with some
> context.  We did consider using Cephes years ago, and even got
> permission from the author to release it under an acceptable license.
> We later decided not to use it for technical reasons.
>=20
> By the way, virtually none of the people who have complained about the
> missing functions actually need them.  Mostly they just want to
> compile some software that was written by a naive programmer who
> thought it would be cool to use the most precise type available.  The
> complex functions are even less commonly needed, and the truth is that
> they have no business being part of the C standard anyway.
>=20
> The question remains of what to do about the missing functions.  Bruce
> and Steve have been working on expl and logl for years.  If those ever
> get in the tree, the remaining long double functions are easy.  Those
> functions are basically done, modulo a bunch of cleanup and testing,
> and I encourage any mathematically inclined folks who are interested
> in pushing things along to get in touch with them.  I'm not going to
> have any time myself for a few months at least.

Where can I find these?

> Lastly, there's the question of mediocre alternatives, such as
> solutions that get the boundary cases wrong or don't handle 128-bit
> floating point.  For the exponential and logarithmic functions, Bruce
> and Steve have already written good implementations, so there's no
> reason to settle for less.  As for the other long double functions,
> bringing in some Cephes code in a separate directory as a temporary
> fix might be the way to go.  I don't like that solution, and Steve
> raises some good technical points about why it isn't ideal; however, a
> better solution is more than a decade overdue, and people are
> justified in finding that unacceptable.

Don't let the perfect be the enemy of the good.  It is better to have OK =
implementations of these functions than none at all.  We originally had =
so-so double support, but bruce spent many years optimizing them to make =
them very good.  If we were just starting out, and hadn't let 10 years =
get behind us, I'd give the substandard argument some weight.  But now =
that we're 13 years down the line from c99's publication I think we need =
to relax our standards a bit.  I'd even argue that these functions being =
a little bad could easily spur people to make them better.  Their =
absence makes people just #define llexp(x) lexp(x), etc. :(

Warner

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?210816F0-7ED7-4481-ABFF-C94A700A3EA0>