delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2007/08/30/18:24:52

X-Spam-Check-By: sourceware.org
Message-ID: <ba40711f0708301524l60319ab8kd8ef0e2c67cc51d7@mail.gmail.com>
Date: Thu, 30 Aug 2007 18:24:16 -0400
From: "Lev Bishop" <lev DOT bishop AT gmail DOT com>
To: cygwin AT cygwin DOT com, newlib AT sourceware DOT org
Subject: Re: 1.5.24: sin() bug
In-Reply-To: <20070829153331.GA95558@tetsuo.karasik.eu.org>
MIME-Version: 1.0
References: <20070829153331 DOT GA95558 AT tetsuo DOT karasik DOT eu DOT org>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 8/29/07, Dmitry Karasik wrote:

> I'd like to submit a bug in cygwin implementation of sin().
<snip>
> the difference is in 7th digit, and is significant for double precision.

This is not a bug in newlib.
The problem is in glibc and msvc and newlib is (more) correct in this case.
Or, to put it another way, the problem is that the 8087 was designed a
few years before the proper theory for doing argument reduction for
trig functions was discovered, and most subsequent x86 compatible
processors (except for the AMD K5) have decided to be bug-compatible
with the original 8087. If you would do your experiment on another
architecture (PowerPC, IA64, x86-64 (assuming glibc built using the
default -msse -mfpmath=sse compiler options) etc) you would get the
same result as from newlib. The C specifications don't require  exact
argument reduction, and so many implementations just return whatever
the underlying hardware implements. This is in opposition to, say,
Java, where the FP rules are more precise. See:
http://blogs.sun.com/jag/entry/transcendental_meditation

Analysis of your testcase:
Closest IEEE-754 double to 3.1415926535897900074 is indeed
0x1.921fb54442d11p+1 (as correctly given by gcc on both cygwin and
linux).

Sin(0x1.921fb54442d110000000000000000) is according to Mathematica:
  0x1.d1a62633145c06e0e690...p-49
the closest IEEE-754 double to this (round-to-even) is
  0x1.d1a62633145c0p-49
as given by newlib.

So, in this case, newlib is getting it right to less than 0.5ulp
(better than 1ulp is all that is usually possible, due to the
table-maker's dilemma). The info file for glibc ("errors in math
functions" node) claims that on ix86 sincos() should be accurate to 1
ulp (it doesn't give an error for sin() alone, but I reworked your
test program to use sincos() and it didn't change the answer). But in
this case, glibc is off by 0x2633145c0 ulps (about 10^10 ulps).

Lev

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019