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 <tony AT dictator DOT nt DOT tuwien DOT ac DOT at>
Subject:	Re: high precision nonlinear math functions ?
In-Reply-To:	<7lF32.59$5O6.224070@lwnws01.ne.mediaone.net>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 981115130608 DOT 1381G-100000 AT is>
Mime-Version:	1.0
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
**************************************************************

- Raw text -