From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 10 13:14:23 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D8AD106566C for ; Wed, 10 Nov 2010 13:14:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id C8D538FC16 for ; Wed, 10 Nov 2010 13:14:22 +0000 (UTC) Received: from c122-107-121-73.carlnfd1.nsw.optusnet.com.au (c122-107-121-73.carlnfd1.nsw.optusnet.com.au [122.107.121.73]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAADEIu2026354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 00:14:19 +1100 Date: Thu, 11 Nov 2010 00:14:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20101110225059.M1461@besplex.bde.org> Message-ID: <20101110235945.K1737@besplex.bde.org> References: <201011092010.oA9KABNt076837@freefall.freebsd.org> <20101110225059.M1461@besplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-419011604-1289394858=:1737" Cc: Ulrich =?utf-8?B?U3DDtnJsZWlu?= , freebsd-bugs@freebsd.org Subject: Re: bin/144306: [libm] [patch] Nasty bug in jn(3) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 13:14:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-419011604-1289394858=:1737 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 10 Nov 2010, Bruce Evans wrote: > On Tue, 9 Nov 2010, Ulrich [utf-8] Sp=C3=B6rlein wrote: >> FreeBSD -CURRENT: >>=20 >> freebsd64# cc -o testjn -lm testjn.c && ./testjn >> 2 4.317548e-01 >> 3 1.989999e-01 >> 4 6.474667e-02 >> 5 1.638924e-02 >> 6 3.404818e-03 >> 7 6.006884e-04 >> 8 9.216579e-05 >> 9 1.251727e-05 > > FreeBSD agrees perfectly with pari. This is not surprising, since only > 7 significant decimal digits are printed and almost 15 should be correct > -- any error here would be an error of about 100 million decimal ulps > or a couple of binary gulps. > >> freebsd64# cc -o testjnf -lm testjnf.c && ./testjnf >> 2 4.317548e-01 >> 3 1.989999e-01 >> 4 6.474666e-02 >> 5 1.638924e-02 >> 6 3.404818e-03 >> 7 6.006881e-04 >> 8 9.216577e-05 >> 9 1.251727e-05 > > This is harder to explain. Now we should only expect 6 digits of accurac= y, > but we are getting 7. Anyway, these are all perfectly rounded according = to > pari. Actually we are getting 6. The last digit differs from the double precisio= n case for args 4, 7 and 8. This is as expected. > [pari output] > Single precision with bad decimal field width: > 2 4.317548e-1 > 3 1.989999e-1 > 4 6.474667e-2 > 5 1.638924e-2 > 6 3.404818e-3 > 7 6.006884e-4 > 8 9.216579e-5 > 9 1.251727e-5 Unfortunately, the correctly rounded (in single precision) result gives (after further rounding to 1 too many decimal digits) values that agree with the double precision C output and thus disagree with the single precision C output. Therefore, the C results in single precision cannot be correctly rounded. I may be confused or have a bug somewhere -- manually rounding the above single precision results to 6 decimal digits gives the same values in all cases, but FLT_DIG =3D 6 is supposed to give enough digits for preserving a single precision result if it is printed and scanned back. When I started replying to this, I thought that extra decimal digits were needed (why is DECIMAL_DIG =3D 21 3 more than LDBL_DIG =3D 18 on i386...?), and printed 3 extra. I left these out to simplify comparisons. Bruce --0-419011604-1289394858=:1737--