Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!reader01.nrc01.news.zen.net.uk.POSTED!not-for-mail From: Nobody Subject: Re: Exact integer-valued floats Date: Sat, 22 Sep 2012 11:19:33 +0100 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.python References: <505ca3e9$0$29981$c3e8da3$5496439d@news.astraweb.com> <7xzk4j6mmq.fsf@ruckus.brouhaha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lines: 26 Organization: Zen Internet NNTP-Posting-Host: 1d0148ae.news.zen.co.uk X-Trace: DXC==KAC:b1@90C2[5 Steven D'Aprano writes: >> Have I got this right? Is there a way to work out the gap between one >> float and the next? > > Yes, 53-bit mantissa as people have mentioned. That tells you what ints > can be exactly represented. But, arithmetic in some situations can have a > 1-ulp error. So I wonder if it's possible that if n is large enough, you > might have something like n+1==n even if the integers n and n+1 have > distinct floating point representations. Not for IEEE-754. Or for any sane implementation, for that matter. OTOH, you can potentially get n != n due to the use of extended precision for intermediate results. For IEEE-754, addition, subtraction, multiplication, division, remainder and square root are "exact" in the sense that the result is as if the arithmetic had been performed with an infinite number of bits then rounded afterwards. For round-to-nearest, the result will be the closest representable value to the exact value. Transcendental functions suffer from the "table-maker's dilemma", and the result will be one of the two closest representable values to the exact value, but not necessarily *the* closest.