Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #106731

Re: how to convert code that uses cmp to python3

Path csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From Antoon Pardon <antoon.pardon@rece.vub.ac.be>
Newsgroups comp.lang.python
Subject Re: how to convert code that uses cmp to python3
Date Sat, 9 Apr 2016 16:25:38 +0200
Lines 70
Message-ID <mailman.118.1460212008.2253.python-list@python.org> (permalink)
References <57064D0D.1030701@rece.vub.ac.be> <CAPTjJmrGiQS9uhFU-+TQ4nUWQ2p4gmJoQitMotS0Ob--qm1iWg@mail.gmail.com> <5706C961.2000009@rece.vub.ac.be> <CAPTjJmrbL870mV1kU8nHar=bPyKZRmhKP-8iUs_tpYVo5vhhOA@mail.gmail.com> <57075F43.7060004@rece.vub.ac.be> <85fuuw5ypl.fsf@benfinney.id.au> <5707B2CE.1010407@rece.vub.ac.be> <CAPTjJmrMv5O5vwrbfHJJCdiHi87naPOanhPmk4Ba_SLRgu1m4Q@mail.gmail.com> <5707BE18.1050805@rece.vub.ac.be> <CAPTjJmoMuqwg0Q_fp=qitC3wWkXYHtdqBNVGzO+3ToAmsgit8Q@mail.gmail.com> <5708C8B0.6050904@rece.vub.ac.be> <85twjb3su5.fsf@benfinney.id.au> <570910E2.3030400@rece.vub.ac.be>
Mime-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8bit
X-Trace news.uni-berlin.de 1/so/Vwwn19CVSdQewHjwAdOQQxXLn0I9+N4gykp209g==
Return-Path <antoon.pardon@rece.vub.ac.be>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.002
X-Spam-Evidence '*H*': 1.00; '*S*': 0.00; 'else:': 0.03; 'elif': 0.04; 'elements.': 0.05; 'subject:code': 0.07; 'happen.': 0.09; 'integers': 0.09; 'lengths': 0.09; 'statistical': 0.09; 'times,': 0.13; 'def': 0.13; 'argument': 0.15; '(true,': 0.16; '__lt__': 0.16; 'cheaper.': 0.16; 'cmp': 0.16; 'former,': 0.16; 'iterables': 0.16; 'nodes': 0.16; 'received:192.168.1.4': 0.16; 'received:adsl- dyn.isp.belgacom.be': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'subject:python3': 0.16; 'traverse': 0.16; 'twice.': 0.16; 'cheap': 0.18; 'implementing': 0.18; 'saying': 0.22; 'delta': 0.22; 'function,': 0.22; 'function:': 0.22; 'keys': 0.22; 'latter': 0.22; 'decide': 0.23; 'header:In- Reply-To:1': 0.24; 'header:User-Agent:1': 0.26; 'example': 0.26; 'least': 0.27; 'comparison': 0.29; 'conditions:': 0.29; 'equality': 0.29; 'once.': 0.29; 'subject:that': 0.29; "i'm": 0.30; 'received:be': 0.30; 'probably': 0.31; 'expensive': 0.32; 'maybe': 0.33; 'point': 0.33; 'problem': 0.33; 'common': 0.33; 'largely': 0.33; 'equal': 0.34; 'could': 0.35; 'possible,': 0.35; 'something': 0.35; 'but': 0.36; 'should': 0.36; 'possible': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'two': 0.37; 'missing': 0.37; 'seem': 0.37; 'difference': 0.38; 'received:192': 0.39; 'to:addr:python.org': 0.40; 'your': 0.60; 'close': 0.61; 'decision': 0.61; 'show': 0.62; 'making': 0.62; 'more': 0.63; 'different': 0.63; 'between': 0.65; 'talking': 0.67; 'claim.': 0.84; 'inflection': 0.84; 'pardon': 0.84; 'parity': 0.84; 'probable,': 0.84; 'received:195.238': 0.84; 'schreef': 0.84; 'tree,': 0.84; 'visit,': 0.84
X-Belgacom-Dynamic yes
X-IronPort-Anti-Spam-Filtered true
X-IronPort-Anti-Spam-Result A2CbAAA+EAlX/2LF9VENUIUHulQBDYFzhg0CgWIUAQEBAQEBAYVOAQEEIw8BRRELGgIFFgsCAgkDAgECAUUTBgICsndnjHeEWwEBCAIefIUlhEuFC4I0glYFmASBVIw4jw2PJh4BAYQragGJKwEBAQ
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0
In-Reply-To <85twjb3su5.fsf@benfinney.id.au>
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.21
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID <570910E2.3030400@rece.vub.ac.be>
X-Mailman-Original-References <57064D0D.1030701@rece.vub.ac.be> <CAPTjJmrGiQS9uhFU-+TQ4nUWQ2p4gmJoQitMotS0Ob--qm1iWg@mail.gmail.com> <5706C961.2000009@rece.vub.ac.be> <CAPTjJmrbL870mV1kU8nHar=bPyKZRmhKP-8iUs_tpYVo5vhhOA@mail.gmail.com> <57075F43.7060004@rece.vub.ac.be> <85fuuw5ypl.fsf@benfinney.id.au> <5707B2CE.1010407@rece.vub.ac.be> <CAPTjJmrMv5O5vwrbfHJJCdiHi87naPOanhPmk4Ba_SLRgu1m4Q@mail.gmail.com> <5707BE18.1050805@rece.vub.ac.be> <CAPTjJmoMuqwg0Q_fp=qitC3wWkXYHtdqBNVGzO+3ToAmsgit8Q@mail.gmail.com> <5708C8B0.6050904@rece.vub.ac.be> <85twjb3su5.fsf@benfinney.id.au>
Xref csiph.com comp.lang.python:106731

Show key headers only | View raw


Op 09-04-16 om 13:49 schreef Ben Finney:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be> writes:
> 
>> You don't seem to understand. I only do two comparisons and no the
>> equality is not necesarrily cheaper.
>>
>> I am talking about the difference between the following two:
>>
>>     if arg.key < node.key:   # possible expensive computation
>>         go_left()
>>     elif arg.key == node.key # possible expensive computation
>>         found_node()
>>     else:
>>         go_right()
>>
>> and
>>
>>     delta = cmp(arg.key, node.key) # possible expensive computation
>>     if delta < 0:                  # cheap computation
>>         go_left()
>>     elif delta == 0:               # cheap computation
>> 	found_node()
>>     else:
>>         go_right()
> 
> I find that a dubious claim.
> 
> The ‘cmp’ implementation must decide *at least* between three
> conditions: less-than, equal-to, greater-than. That is *at least* two
> inflection points.
> 
> The implementation of ‘__lt__’ and the implementation of ‘__eq__’ each
> only need to decide two conditions (true, false). So that is *at most*
> two inflection points.
> 
> If you're saying the latter implementation is somehow *more* expensive
> than the former, I think the implementations are suspect and likely can
> be improved: at least parity should be possible, to the point of
> statistical insignificance.

Let me give you an artifical example to show what can happen. The keys are all
iterables of equal lengths with integers as elements.

Then this could be the cmp function:

def cmp(ob1, ob2):
    itr1 = iter(ob1)
    itr2 = iter(ob2)
    for el1, el2 in zip(itr1, itr2)
        delta = el1 - el2
        if delta != 0:
            return delta
    return 0

Now maybe I'm missing something but I don't see how implementing __lt__ and
__eq__ in this case will be much different from largely reimplenting cmp.
So if you can work with a cmp function, you only need to travese the two
iterables only once. If you do it with the __lt__ and __eq__ methods you
will have to traverse them twice.

Now this probably is not a problem most of the times, but when you work with
tree's this kind of comparison to make a three way decision happens often and
the lower you descend in the tree, the close your argument will be with the
keys of the nodes you visit, making it more and more probable, you have a
large common prefix.

So in these circumstances it is more likely to be problematic.

-- 
Antoon Pardon

Back to comp.lang.python | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Re: how to convert code that uses cmp to python3 Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-04-09 16:25 +0200
  Re: how to convert code that uses cmp to python3 Marko Rauhamaa <marko@pacujo.net> - 2016-04-09 17:54 +0300

csiph-web