From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: libm question Date: 11 Jul 2001 11:10:13 GMT Organization: Aachen University of Technology (RWTH) Lines: 52 Message-ID: <9ihc6l$ngl$1@nets3.rz.RWTH-Aachen.DE> References: NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 994849813 24085 137.226.32.75 (11 Jul 2001 11:10:13 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 11 Jul 2001 11:10:13 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Patrick Mitran wrote: > 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. Not completely portable, but reasonably portable. You could use 'autoconf' to automatically detect if the system your program runs on has erfc(), already, and only compile in your own fallback version if it doesn't (read about AC_REPLACE_FUNC in the autoconf docs). > I though I could just copy the function body into something called > my_erfc() and voila, no problems with portability now. But possible problems with Copyright, in exchange. You'll have to read the Copyright applying to the libm sources carefully to see whether you're allowed to rip a single function out of it just like that. > 1. erfc() is implemented as a polynomial curve fit ( no surprise) It's not. It's quite a bit more complicated than that. It's implemented by selecting one out of a collection of formulas for different argument ranges, only some of which are simple polynomials. erfc(), e.g. is mainly a ratio of two polynomials, with an exponential applied afterwards. > 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? Because this code doesn't make the assumption that it runs on an Intel FPU, in this particular place. > Also, I tried compiling a trivial file that just computed sin(2.0) with no > #include "math" or -lm and it worked! Partly by luck. You should at least have included math.h, as otherwise, you're calling a function without a prototype declaration for it in scope. It's linking with -lm that would make the difference, not #include "math.h". > 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! That's because gcc itself has a builtin implementation of sin(), IIRC. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.