On 09.07.2012 01:36 (UTC+2), Steve Kargl wrote:
On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote:
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 <s...@troutmask.apl.washington.edu>
wrote:
Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.
Well, most of cephes was written before C99. The C99 parts of
cephes were written to turn it into a complete C99 implementation.
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.
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.
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?
I've posted expl() a few times for the ld80 version.
I don't have an ld128 version, which is why I have
yet to submit a formal patch for expl(). I also
have an ld80 expm1l(). I have a copy of bde's ld80
logl(). IIRC, bde wrote an ld128, but I don't have
nor do I know if it has been tested.
Do you think your version from
http://www.freebsd.org/cgi/query-pr.cgi?pr=152415 for expl() ld80
version could be the one getting into head? Would you be willing to
commit it?
As far as I understand from discussions on R mailing list
(r-de...@r-project.org), they plan to reduce the emulation and/or
workaround of long and complex math functions for FreeBSD and other
systems with their next releases of R devel. So we could really need
some progress with our C99 conform math functions ;-)
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.
You'll need to define OK, because some of the implementations
I've read are poor. I also hope that before anything is
committed to libm that the person doing the committing does
some rather thorough testing of the code.
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. :(
Of course, the converse argument is that people have had 10 years
to learn enough about floating point to actually write and submit
code. I knew very little about FP before I wrote sqrtl(). I had
a need for sqrtl() and so I went looking for a solution.
PS: I also wrote sincos[fl](), which is very handy for the
complex trig functions.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
