Message-Id: <4.1.19981116091759.00abe6f0@hal.nt.tuwien.ac.at> X-Sender: tony AT dictator DOT nt DOT tuwien DOT ac DOT at X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 16 Nov 1998 09:47:46 +0100 To: djgpp AT delorie DOT com From: Anton Helm Subject: Re: high precision nonlinear math functions ? In-Reply-To: <7lF32.59$5O6.224070@lwnws01.ne.mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: djgpp AT delorie DOT com At 18:47 15.11.98 +0000, you wrote: >: > Is there any math lib available that can do these >: > computations in long double ? > >The specific problem you posed is due to cancellation error. It should >not require extra precision. After receiving several messages about my "stupid coding" (yes someone actually used this wording...) I testify here and now that I did _NOT_ implement the examples given directly. The code is heavily rearranged to take care of numerical effects. I just didn't want to confuse people here on the list who don't know such techniques. Numeric precision still _IS_ a problem as I use these algorithms on several unix hosts (where there are such functions in long double) with much better results. >If you want to resurrect the long double functions that used >to exist, look at djgpp/src/libc/ansi/math. For the most part >you just need to change instructions like fldl to fldt and fix >a few constants from double to long double. Someone actually removed them from current library ??? Why ? Maybe because in ANSI they are definded as double precision functions, but couldn't it be possible to supply them whith different names, e.g. ld_sin() and wrap them with a #ifndef ANSI in math.h ? I gonna dig into the sources in the next days. >: ``Long double'' and ``fast'' don't live together well enough ;-). Hmmm. I know. But what's life without dreams... >In x86 coprocessors, not only the arithmetic but also the elementary >functions like log and tan are computed in long double anyway, >so there is essentially no speed difference. >In many cases the new libm is actually less accurate than the >coprocessor functions because the coprocessor results are long >double but fdlibm was not designed to take advantage of long double. >Consequently the fdlibm functions have more roundoff error. >For practical calculations there is no reason to prefer the new libm >over the coprocessor. Thanks. I gonna look into this. Tony ************************************************************** Dipl.-Ing. Anton HELM *T* mailto:tony AT nt DOT tuwien DOT ac DOT at Institut fuer *U* http://www.nt.tuwien.ac.at/~tony/ Nachrichtentechnik und *W* http://www.nt.tuwien.ac.at/ Hochfrequenztechnik *I* talkto:tony AT eagle DOT nt DOT tuwien DOT ac DOT at Guszhausstr. 25/389 *E* phoneto:+43-1-58801-38920 A-1040 Wien, AUSTRIA *N* faxto:+43-1-5870583 ************************************************************** finger -l tony AT penguin DOT nt DOT tuwien DOT ac DOT at for PGP public key **************************************************************