From owner-freebsd-current@FreeBSD.ORG Thu Aug 4 16:50:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B046B16A420 for ; Thu, 4 Aug 2005 16:50:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F31E43D53 for ; Thu, 4 Aug 2005 16:50:08 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id BBE025CC7; Thu, 4 Aug 2005 12:50:07 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33789-06; Thu, 4 Aug 2005 12:49:57 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-54-113.ny325.east.verizon.net [68.161.54.113]) by pi.codefab.com (Postfix) with ESMTP id 0D63B5C99; Thu, 4 Aug 2005 12:49:56 -0400 (EDT) Message-ID: <42F24737.2060705@mac.com> Date: Thu, 04 Aug 2005 12:49:59 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Kargl References: <20050804162618.GA96657@troutmask.apl.washington.edu> In-Reply-To: <20050804162618.GA96657@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-current@freebsd.org Subject: Re: Number of significand bits in long double? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 16:50:17 -0000 Steve Kargl wrote: > Can someone confirm or refute that the long double type > has 53 bits in its significand on i386? Which header > file in /usr/include provides this info? /usr/include/float.h ...? You may wish to examine the enquire.c program from: http://homepages.cwi.nl/~steven/enquire.html ...which has been bundled with GCC and maybe other things, too. On a FreeBSD/i386 system using a P3 CPU: PROPERTIES OF DOUBLE Base = 2 Significant base digits = 53 (= at least 15 decimal digits) Arithmetic rounds towards nearest Tie breaking rounds to even Smallest x such that 1.0-base**x != 1.0 = -53 Smallest x such that 1.0-x != 1.0 = 5.5511151231257839e-17 Smallest x such that 1.0+base**x != 1.0 = -52 Smallest x such that 1.0+x != 1.0 = 1.1102230246251568e-16 (Above number + 1.0) - 1.0 = 2.2204460492503131e-16 Number of bits used for exponent = 11 Minimum normalised exponent = -1022 Minimum normalised positive number = 2.2250738585072014e-308 The smallest numbers are not kept normalised Smallest unnormalised positive number = 4.9406564584124654e-324 Maximum exponent = 1024 Maximum number = 1.7976931348623157e+308 Overflow doesn't seem to generate a trap There is an 'infinite' value Divide by zero doesn't generate a trap Arithmetic uses a hidden bit It looks like double length IEEE format PROPERTIES OF LONG DOUBLE Base = 2 Significant base digits = 53 (= at least 15 decimal digits) Arithmetic rounds towards nearest Tie breaking rounds to even Smallest x such that 1.0-base**x != 1.0 = -53 Smallest x such that 1.0-x != 1.0 = 5.5511151231257839e-17 Smallest x such that 1.0+base**x != 1.0 = -52 Smallest x such that 1.0+x != 1.0 = 1.1102230246251568e-16 (Above number + 1.0) - 1.0 = 2.2204460492503131e-16 Number of bits used for exponent = 15 Minimum normalised exponent = -16382 Minimum normalised positive number = 0.0000000000000000e+00 *** WARNING: Possibly bad output from printf above expected value around 3.3621031431121065e-4932, bit pattern: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 10000000 00000001 00000000 00001111 00101000 sscanf gave 0.0000000000000000e+00, bit pattern: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 00001000 difference= 0.0000000000000000e+00 The smallest numbers are not kept normalised Smallest unnormalised positive number = 0.0000000000000000e+00 *** WARNING: Possibly bad output from printf above expected value around 7.4653686412953384e-4948, bit pattern: 00000000 00001000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001111 00101000 sscanf gave 0.0000000000000000e+00, bit pattern: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 00001000 difference= 0.0000000000000000e+00 Maximum exponent = 16384 Maximum number = Inf *** WARNING: Possibly bad output from printf above expected value around 1.1897314953572353e4932, bit pattern: 00000000 11111000 11111111 11111111 11111111 11111111 11111111 11111111 11111110 01111111 00001111 00101000 sscanf gave 0.0000000000000000e+00, bit pattern: 10101010 00011110 00001010 00101000 00000001 00000000 00000000 00000000 00000000 00000000 00000101 00001000 difference= Inf Overflow doesn't seem to generate a trap There is an 'infinite' value Divide by zero doesn't generate a trap Only 68 of the 96 bits of a long double are actually used It doesn't look like IEEE format Float expressions are evaluated in double precision Double expressions are evaluated in double precision Long double expressions are evaluated in double precision -- -Chuck