Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Jun 2004 15:51:46 -0700 (PDT)
From:      David Schultz <das@FreeBSD.org>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs
Message-ID:  <200406012251.i51MpkkU024224@VARK.homeunix.com>
Resent-Message-ID: <200406012300.i51N0lSv011591@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         67469
>Category:       i386
>Synopsis:       src/lib/msun/i387/s_tan.S gives incorrect results for large inputs
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 01 16:00:46 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     David Schultz
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
>Environment:
>Description:
src/lib/msun/i387/s_tan.S returns wildly inaccuate results when
its input has a large magnitude (>> 2*pi).  For example:

input			s_tan.S				k_tan.c
1.776524190754802e+269	1.773388446261095e+16		-1.367233274980565e+01
1.182891728897420e+57	-1.9314539773999572e-01		1.0020569035866138e+03
2.303439778835110e+202	2.8465460220132694e+00		3.5686329695133922e+00

I suspect that this is caused in the modular reduction phase, which is
used for inputs with magnitude greater than 2^63.  In these cases, the
inputs are taken mod 2*pi, but the double precision representation of
pi isn't precise enough to obtain a meaningful result for this
computation.

>How-To-Repeat:

>Fix:
One solution might involve doing the reduction using
__ieee754_rem_pio4() instead of the fprem1 instruction.
Unfortunately, since this uses pi/2 as the modulus, it
is necessary to apply the identity tan(x + pi/2) = -1/tan(x)
for odd-phase inputs.  I tried this for the first example
input above and got an answer that was off by 2 ulps.  Close,
but the MI implementation gets within 1 ulp.  I'm not sure what
kind of correction (if any) should be used here.

This PR exists mainly as a reminder for me or anyone else who wants to
look at it more carefully some lazy Saturday afternoon.  I can't
imagine many people care what the tangent of 10 billion is, but the
tan() function *is* supposed to give the correct answer.
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406012251.i51MpkkU024224>