From: "Patrick Mitran" 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: 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