Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.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.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'preferred.': 0.04; 'cpython': 0.05; 'received:verizon.net': 0.07; 'returned.': 0.07; 'terry': 0.07; 'python': 0.08; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:80.91.229.12': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'received:lo.gmane.org': 0.09; 'solution,': 0.09; 'tuple': 0.09; 'output': 0.10; 'am,': 0.12; 'processor': 0.15; 'subject:was': 0.15; 'cpython,': 0.16; 'exposes': 0.16; 'expressions;': 0.16; 'messy': 0.16; 'reedy': 0.16; 'subject: \n ': 0.16; 'subject:syntax': 0.16; 'wouldnt': 0.16; 'wrote:': 0.18; '>>>': 0.18; 'computing': 0.18; 'arguments': 0.18; 'have:': 0.18; 'jan': 0.19; 'subject:not': 0.21; '(or': 0.22; 'header:In-Reply-To:1': 0.22; 'division': 0.23; 'once.': 0.23; 'though.': 0.23; 'index': 0.24; 'explicitly': 0.29; 'ignored.': 0.29; 'indicated': 0.29; 'calculated': 0.30; 'implicitly': 0.30; 'operation.': 0.30; 'semantics': 0.30; 'wraps': 0.30; '(as': 0.31; 'does': 0.32; 'subject:]': 0.32; 'header:User-Agent:1': 0.33; 'actually': 0.33; 'header:X-Complaints-To:1': 0.33; 'instead': 0.33; 'there': 0.33; 'together.': 0.34; 'to:addr:python-list': 0.34; 'calling': 0.34; 'another.': 0.34; 'elegant': 0.34; 'integer': 0.34; 'puts': 0.34; 'however,': 0.36; 'two': 0.37; 'but': 0.37; 'could': 0.37; 'cases,': 0.38; 'received:org': 0.38; 'returned': 0.39; 'clearly': 0.39; 'should': 0.39; 'define': 0.39; 'why': 0.39; 'to:addr:python.org': 0.40; 'might': 0.40; 'once': 0.60; 'more': 0.61; 'lower': 0.64; 'believe': 0.65; 'composite': 0.84; 'hand.': 0.84 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Terry Reedy Subject: Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Date: Wed, 14 Dec 2011 15:57:40 -0500 References: <4ee81592$0$11091$c3e8da3@news.astraweb.com> <78d2ba1b-0ea2-49a8-88f4-d85186bb2317@f11g2000yql.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gmane-NNTP-Posting-Host: pool-74-109-121-73.phlapa.fios.verizon.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <78d2ba1b-0ea2-49a8-88f4-d85186bb2317@f11g2000yql.googlegroups.com> X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 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: 53 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1323896280 news.xs4all.nl 6972 [2001:888:2000:d::a6]:36453 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:17236 On 12/14/2011 5:09 AM, Eelco wrote: > Arguably, the most elegant thing to do is to define integer division > and remainder as a single operation; It actually is, as quotient and remainder are calculated together. The microprocessors I know of expose this (as does Python). 'a divmod b' puts the quotient in one register and the remainder in another. If you ask for just one of the two values, both are calculated and one is grabbed while the other is returned. > which is not only the logical > thing to do mathematically, but might work really well > programmatically too. > > The semantics of python dont really allow for this though. One could > have: > > d, r = a // b >>> a,b = divmod(10,3) >>> a,b (3, 1) With CPython, int.__divmod__ lightly wraps and exposes the processor operation. > But it wouldnt work that well in composite expressions; selecting the > right tuple index would be messy and a more verbose form would be > preferred. That is why we have >>> a == 10 // 3 True >>> b == 10 % 3 True In both cases, I believe CPython calls int.__divmod__ (or the lower level equivalent) to calculate both values, and one is returned while the other is ignored. It it the same when one does long division by hand. > However, performance-wise its also clearly the best > solution, as one often needs both output arguments and computing them > simultaniously is most efficient. As indicated above, there is really no choice but to calculate both at once. If one needs both a//b and a%b, one should explicitly call divmod once and save (name) both values, instead of calling it implicitly twice and tossing half the answer each time. -- Terry Jan Reedy