From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 11:24:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86E44C0D; Sat, 15 Dec 2012 11:24:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 142DB8FC0A; Sat, 15 Dec 2012 11:24:53 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBFBOnEA019642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 22:24:51 +1100 Date: Sat, 15 Dec 2012 22:24:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oliver Pinter Subject: Re: [RFC/RFT] calloutng In-Reply-To: Message-ID: <20121215222156.H2309@besplex.bde.org> References: <20121215183409.U1603@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zvi1sKHG c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=NQ0KR7aI5Mbd9Gopmc4A:9 a=CjuIK1q_8ugA:10 a=oZ2IPoelaH8A:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Sat, 15 Dec 2012 12:28:24 +0000 Cc: Davide Italiano , freebsd-current , Bruce Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 15 Dec 2012 11:24:54 -0000 On Sat, 15 Dec 2012, Oliver Pinter wrote: > On 12/15/12, Bruce Evans wrote: >> ... >> Because of the different grouping of the multiplications, the second >> is unfortunately slower (1 more multiplication that cannot be done at >> compile time). The second also gives unnecessary (but findamental to >> the method) inaccuracy by pulling out the factor of 1000. The first >> gives the same inaccuracy, and now it is because the constant is not >> correctly rounded. It should be >> >> 2.0**64 / 10**3 = 1844674407309551.616 (exactly) >> = 1844674407309552 (rounded to nearest int) >> >> but is actually rounded down to a multiple of 1000. >> ... mav@ already fixed the rounding before I wrote that :-). He also changed some (uint64_t)1's to use the long long abomination :-(. > Thanks for the detailed answer. :) Bruce