Date: Tue, 16 May 2000 17:23:04 -0400 (EDT)
Message-Id: <200005162123.RAA20140@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: rudd AT cyberoptics DOT com
CC: djgpp-workers AT delorie DOT com
In-reply-to: <39215B01.340A5CC2@cyberoptics.com> (message from Eric Rudd on
	Tue, 16 May 2000 09:28:17 -0500)
Subject: Re: Math functions
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000516143219 DOT 24814F-100000 AT is> <39215B01 DOT 340A5CC2 AT cyberoptics DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Tue, 16 May 2000 09:28:17 -0500
> From: Eric Rudd <rudd AT cyberoptics DOT com>
> 
> The
> question is whether a user doing normal double-precision computations
> would ever be materially affected by such errors.  If I could exhibit a
> practical computation that succeeded with perfect range reduction, but
> failed with 66-bit range reduction, then one would have a practical
> objection.  I was attempting to argue that the difficulty of devising such
> a computation (without resorting to multiple precision) is by itself a
> good indication that these errors are of no consequence to most users.

It is my understanding that whoever needs long double math functions
will run the entire program with long double arithmetics, not with
double-precision.