Date: Tue, 16 May 2000 09:28:17 -0500
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: Math functions
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
Message-id: <39215B01.340A5CC2@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000516143219 DOT 24814F-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> On Mon, 15 May 2000, Eric Rudd wrote:
>
> > Nor can I.  The decisive argument for me was my inability to
> > conceive of any test of "double" trig functions that used only
> > "double" arithmetic, yet managed to reveal such range-reduction
> > errors.
>
> Perhaps some multiple-precision package could help.  Using it, you could
> create test cases, like djtst does in the Cygnus test suite part by
> using Steven Mishier's quad-precision functions, and then run the long
> double functions on those test cases.  MP code is slow, but since you
> only generate the test cases once, this should not be a problem.

Yes, I already have such a test program, but that wasn't my point.  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.

-Eric Rudd
rudd AT cyberoptics DOT com