Date: Mon, 16 Nov 1998 10:17:20 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: moshier AT mediaone DOT net cc: djgpp AT delorie DOT com Subject: Re: high precision nonlinear math functions ? In-Reply-To: <7lF32.59$5O6.224070@lwnws01.ne.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Sun, 15 Nov 1998 moshier AT mediaone DOT net wrote: > : ``Long double'' and ``fast'' don't live together well enough ;-). > > 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. True, but that's not what I meant. Going to long double 80-bit format most probably won't solve any significant problems in this case, since (a) many functions in the posted snippet would be inlined by GCC (and thus execute at native 80-bit precision) anyway; and (b) AFAIK GCC holds intermediate results on the FP stack in 80-bit format, unless told otherwise. Since the offending computations, as we were told, run in the innermost loop, I'm led to believe that most of that code uses 80-bit long doubles already. I was thinking about more than 80-bit precision, which would need to be done in software and thus be slow. I'm sorry I used the confusing term ``long double'' which obscured my idea. > : The new libm from the beta release of v2.02 should be more accurate, > : so you might give it a try. > > 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. The cited fragment made a comparison between the old libm.a from v2.01 (used by the original poster, as he told in his message) and the version from recent v2.02 betas. Testing shows that the new version is more accurate than the old one. In fact, testing also shows that the new libm.a is more accurate than the ANSI math functions which are part of libc.a. While it is true that improved versions of those functions can be written using the coprocessor, the current versions are less accurate than libm. Eric Rudd is working on improved coprocessor-based versions, AFAIK.