From:	"Patrick Mitran" <pmitran AT tsp DOT ece DOT mcgill DOT ca>
Newsgroups:	comp.os.msdos.djgpp
Subject:	libm question
Lines:	31
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID:	<m6K27.21468$Sh2.1265904@carnaval.risq.qc.ca>
Date:	Tue, 10 Jul 2001 21:05:22 GMT
NNTP-Posting-Host:	198.168.182.86
X-Complaints-To:	abuse AT mcgill DOT ca
X-Trace:	carnaval.risq.qc.ca 994799122 198.168.182.86 (Tue, 10 Jul 2001 17:05:22 EDT)
NNTP-Posting-Date:	Tue, 10 Jul 2001 17:05:22 EDT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

This all started with me trying to use the erfc() function (which I
did manage), but it opened a whole bunch of questions.

The program I'm writting should eventually run on unix/Linux boxes (for
my personal use only) so using the erfc() is not going to make my code
portatble.
 I though I could just copy the function body into something called
my_erfc()
and voila, no problems with portability now. However, after looking at the
sources of libm, it became clear that this would not be easy.

1. erfc() is implemented as a polynomial curve fit ( no surprise)
2. erfc calls ___ieee574_exp() which as far as I can tell is an
    exponential function also implemented as a polynomial curve fit.

The last point raised an eyebrow. Why a curve fit when intel FPUs can
do exponentiation? A quick look at libm showed that all the numerical
functions are polynomial curve fits!

Also, I tried compiling a trivial file that just computed sin(2.0) with no
#include "math" or -lm and it worked! Not only that, but when I
disassembled it with gdb, the _sin function wasn't the one in libm, it
actually used the fsin instruction! I'm pretty sure that on a Sun
machine with gcc this would not have compiled.

What's going on here?

Patrick

- Raw text -