Path: csiph.com!usenet.pasdenom.info!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!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.017 X-Spam-Evidence: '*H*': 0.97; '*S*': 0.00; 'else:': 0.03; 'linear': 0.09; 'optimizing': 0.09; 'slices': 0.09; 'stack.': 0.09; 'working:': 0.09; 'cc:addr:python-list': 0.11; 'def': 0.12; 'backward': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'hard-coded': 0.16; 'integers,': 0.16; 'min:': 0.16; 'values:': 0.16; 'values[0]': 0.16; 'wrote:': 0.18; 'not,': 0.20; 'seems': 0.21; 'cc:addr:python.org': 0.22; 'comparing': 0.24; 'form:': 0.24; 'instance,': 0.24; 'cc:2**0': 0.24; 'certain': 0.27; 'values': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'am,': 0.29; "doesn't": 0.30; 'message- id:@mail.gmail.com': 0.30; 'code': 0.31; '(maybe': 0.31; 'fixing': 0.31; 'operations.': 0.31; 'way?': 0.31; 'run': 0.32; 'becomes': 0.33; 'subject:time': 0.33; "can't": 0.35; 'etc': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'really': 0.36; 'positive': 0.37; 'version,': 0.38; 'list,': 0.38; 'realize': 0.39; 'how': 0.40; 'even': 0.60; 'impact': 0.61; "you're": 0.61; 'complete': 0.62; 'such': 0.63; 'more': 0.64; 'effectively': 0.66; 'obvious': 0.74; 'surprise': 0.74; '2015': 0.84; 'algorithm,': 0.84; 'min': 0.84; 'inefficient': 0.91; 'to:none': 0.92; 'state.': 0.95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=Vh7YDHNugozrnW/mS4j7jmyBVJzFUyk20w63VaSgDUY=; b=tSy+EgmdGiWsBq0XZ2qkX+Emf0bhW9ru3TR+shNnQobxhiU84RYBcKfge7r4AX3bf9 Y/+/RCf0YTojk5eX/xk8S9kBBdQmkGHj5Ys1fmKL5sHyiCdc1qK9pFMoxZx2yGO/zhIK n06Yv6mWJE3JPsM/68iLxkwoCx6mflxIesk+xuO6u+5gNpPEIbQD3DhR0GRYU2cu6xI9 X9x2Xkv4j7aVcPyVBT/ER5+WjlPqghLO0KAbe+pEJZDBS6Q+kDc4BIOxmASInBCis0aI lG2Qn7pd3yDetQpvTc3DiJ1w+4NsofYJjHg4oTjQQBQCr5KPxzfvlsKAwyAFXb/ouwxY SCRA== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr14959102icb.59.1431977804716; Mon, 18 May 2015 12:36:44 -0700 (PDT) In-Reply-To: <9ceklad15llnv3npejq9iuh91soci8aeqo@4ax.com> References: <9ceklad15llnv3npejq9iuh91soci8aeqo@4ax.com> Date: Tue, 19 May 2015 05:36:44 +1000 Subject: Re: Slices time complexity From: Chris Angelico Cc: "python-list@python.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ 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: 47 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1431977807 news.xs4all.nl 2969 [2001:888:2000:d::a6]:55863 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:90808 On Tue, May 19, 2015 at 5:23 AM, Mario Figueiredo wrote: > From the above link it seems slices work in linear time on all cases. > And this really has a big impact on certain operations. For instance, > the code below may surprise some people when they realize it doesn't > run in linear time on 3.4: > > def minimum(values): > if len(values) == 1: > return values[0] > else: > m = minimum(values[1:]) > return m if m < values[0] else values[0] https://xkcd.com/1270/ Is there really a reason to code this in such a bizarrely inefficient way? Linear or not, it's bound to be less efficient than the more obvious form: def minimum(values): values = iter(values) min = next(values) for value in values: if value < min: min = value return min And if you know your value domain (maybe you're working with floats, or positive integers, or something) and can put a hard-coded base value in, it becomes even simpler: def minimum(values): min = 0 # or float("-inf") etc for value in values: if value < min: min = value return min It's obvious that this code will complete in linear time. It's also pretty obvious how it's working: it steps through the collection, comparing each value against the current smallest. With your recursive version, it effectively steps backward through the list, comparing each value against the current smallest, all while unwinding the stack. It can't even be tail-call-optimized in its current state. What's the point of optimizing slicing to allow you to use a poor algorithm, instead of fixing your algorithm? ChrisA