On 05/28/2012 05:17 PM, Steve Kargl wrote:
On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
On 05/28/2012 03:31 PM, Steve Kargl wrote:
On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
One thing that could be done is to have a "math/cephes" port that adds
the extra C99 math functions. This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.
What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well. It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.
What do you guys think? Do you want someone to start experimenting with
this idea? I could do it, but probably not for a little while.
This is a horrible, horrible, horrible idea. Have you
looked at the cephes code, particularly the complex.h
functions?
I have only taken a very cursory look. What should I specifically look
for in seeing that the code is bad?
Well, to start with, the extra C99 math functions that
are missing in libm include a few for the long double type
and many (if not most) of the complex functions for any
type. Cephes at best will give you float, double, and ld80, but
not ld128 versions of the functions. Then, there is fun little fact
that neither (base) gcc nor clang nor gcc less than 4.6 does
complex arithematic correctly; so, one needs to jump through
hoops to get the correct answer (See Annex G in n1256.pdf).
One item of particular importance in Annex G is the behavior
of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
NaN.
IMHO these problems are definitely not bad enough to avoid making a
math/cephes port. I for one would definitely like to have some kind of
implementation of ccosh, even if it gets a few things wrong when it is
fed Nan or I*Inf or such like as its input. I mean, if clang or gcc46
doesn't even get this right, how can we expect better from libm?
Also, a really nice thing about Jeremy's patch is that it automatically
detects which functions are already included in the base libm, and only
adds functions not already in libm.
And ld80 is better than nothing if ld128 isn't available.
I would avoid cephes only if it got some of the answers horribly wrong
(as in erf(100) being something like -14232 as the openoffice
implementation of the erf function used to report).
I say, lets go ahead and add a math/cephes port.
By the way, do you have an opinion on the complex functions used in
Linux? (I tried reading the glibc code, but I could only find chains of
macros and functions calling each other, and I could never find where
the actual work was performed.)
_______________________________________________
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"
