delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/07/11/07:15:24

From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
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: <m6K27.21468$Sh2 DOT 1265904 AT carnaval DOT risq DOT qc DOT ca>
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 <pmitran AT tsp DOT ece DOT mcgill DOT ca> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019