delorie.com/archives/browse.cgi | search |
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 |
> 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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |