Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.030 X-Spam-Evidence: '*H*': 0.94; '*S*': 0.00; 'mrab': 0.05; 'float': 0.07; 'string': 0.09; 'formatting': 0.09; 'integers': 0.09; 'pretend': 0.09; 'did.': 0.16; 'formatted': 0.16; 'precision.': 0.16; 'rounding': 0.16; 'wrote:': 0.18; 'all,': 0.19; 'trying': 0.19; 'certainly': 0.24; 'fraction': 0.24; 'mon,': 0.24; 'header :In-Reply-To:1': 0.27; 'point': 0.28; 'correct': 0.29; 'chris': 0.29; 'am,': 0.29; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'division': 0.31; 'occurs': 0.31; 'candidate': 0.34; 'could': 0.34; 'equal': 0.35; 'operations': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; "didn't": 0.36; 'similar': 0.36; 'should': 0.36; 'being': 0.38; 'loss': 0.38; 'to:addr:python-list': 0.38; 'pm,': 0.38; 'to:addr:python.org': 0.39; 'worry': 0.60; 'become': 0.64; 'more': 0.64; 'relatively': 0.65; 'worth': 0.66; 'jul': 0.74; 'prime': 0.74; 'subject:results': 0.91; 'imagine': 0.93; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=pvV0CguDo9aNxvjJKx7JFa4Zh8fR0MvAtXwhDPw4T9Q=; b=IzbJ5zNVn+WXsWlq/OKZc47JOYqSOaKlSnE0j/mVYcpCJEvojM39pUP+vElql/oVhW DGt5WWehx8qUcOCtltM8kM/IOetYx9LuT3Zql4UNfphfbNiDPnM9COB665/uT8HexDMa 51ia6a1uuURErLY1mn3zOSQXjIjBCpSdJ/R0+LjGb9ztayY5Zu42bYdNBa7923HAINlN 5VAHm3yX/ryS81pnVgr7V0hzQsFz2CUdeF9DAUXbtcp24Vkd/jCUQA/iOzxsCGRud/qs mYdvuTYL9RSkhxhrnjrMTRDYDP1h6MwFFSGkZgiy56UichvS6nKMxNKrLjt64Qs71NQf QNng== X-Received: by 10.66.164.199 with SMTP id ys7mr23258984pab.104.1375116092872; Mon, 29 Jul 2013 09:41:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <51f68d9c$0$30000$c3e8da3$5496439d@news.astraweb.com> <51F693B4.9000201@mrabarnett.plus.com> From: Ian Kelly Date: Mon, 29 Jul 2013 10:40:52 -0600 Subject: Re: Unexpected results comparing float to Fraction To: Python Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 21 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1375116584 news.xs4all.nl 15969 [2001:888:2000:d::a6]:50785 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:51461 On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote: > On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote: >> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats >> are approximate anyway, and the float value 1/3 is more likely to be >> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984). > > At what point should it become Fraction(1, 3)? At the point where the float is exactly equal to the value you get from the floating-point division 1/3. If it's some other float then the user didn't get there by entering 1/3, so it's not worth trying to pretend that they did. We do a similar rounding when formatting floats to strings, but in that case one only has to worry about divisors that are powers of 10. I imagine it's going to take more time to find the correct fraction when any pair of relatively prime integers can be a candidate numerator and denominator. Additionally, the string rounding only occurs when the float is being formatted for display; we certainly don't do it as the result of numeric operations where it could result in loss of precision.