[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-list
Subject:    Re: Would there be support for a more general cmp/__cmp__
From:       Ron Adam <rrr () ronadam ! com>
Date:       2005-10-28 14:55:33
Message-ID: FZq8f.214897$p_1.49124 () tornado ! tampabay ! rr ! com
[Download RAW message or body]



Antoon Pardon wrote:
> Op 2005-10-26, Ron Adam schreef <rrr@ronadam.com>:
> 
>>Adding complexity to cmp may not break code, but it could probably slow 
>>down sorting in general.  So I would think what ever improvements or 
>>alternatives needs to be careful not to slow down existing sorting cases.
> 
> As a result of Bengt's post, I rewrote my test program, this is the
> program now.

...

> These are the results.
> 
> <class '__main__.cla'>: 1000 repeats, 1000 long, 10.061425 secs
> <class '__main__.clb'>: 1000 repeats, 1000 long,  9.544035 secs
> <class '__main__.clc'>: 1000 repeats, 1000 long, 10.450864 secs
> <class '__main__.cld'>: 1000 repeats, 1000 long, 15.566061 secs
> <class '__main__.cle'>: 1000 repeats, 1000 long, 15.776443 secs
> 
> Results on a longer sequence were:
> 
> <class '__main__.cla'>: 1000 repeats, 10000 long, 146.722443 secs
> <class '__main__.clb'>: 1000 repeats, 10000 long, 139.480863 secs
> <class '__main__.clc'>: 1000 repeats, 10000 long, 152.623424 secs
> <class '__main__.cld'>: 1000 repeats, 10000 long, 224.630926 secs
> <class '__main__.cle'>: 1000 repeats, 10000 long, 228.663825 secs
> 
> The most interesting result of this test is the difference between
> cld and cle. IMO this difference is an indication of the cost
> that my idea would have on sorting, should it be implemented.
> That would be around 2%. I think that is bearable. Especially
> since this were very simple routines. The moment the comparison
> calculation become heavier, the relative contribution of the
> try: except will diminuish.


class cle:
   def __init__(self, i):
     self.value = int(i)

   def __comp__(self, other):
     return self.value - other.value

   def __lt__(self, other):
     try:
       return self.__comp__(other) < 0
     except UnequalValues:
       return False


This would only work with numeric types. I believe that cmp is closer to 
the following.

     return ( self.value < other.value and -1
              or self.value > self.value and 1
              or 0 )

I don't think it effects the speed a great deal however.


> If you are concerned about sorting times, I think you should
> be more concerned about Guido's idea of doing away with __cmp__.
> Sure __lt__ is faster. But in a number of cases writing __cmp__
> is of the same complexity as writing __lt__. So if you then
> need a __lt__, __le__, __eq__, __ne__, __gt__ and __ge__ it
> would be a lot easier to write a __cmp__ and have all rich
> comparisons methods call this instead of duplicating the code
> about six times. So you would be more or less forced to write
> your class as class cld or cle. This would have a bigger
> impact on sorting times than my suggestion.

I haven't heard he was removing __cmp__, but I would think the sort or 
sorted functions would just use the available comparisons methods or 
equivalent C code for base types.  So I expect it would only matter if 
you need a custom or modified sort.

Although It is a thought that these cases could be improved by making 
the sort value available to the underlying C sort function.  Something 
on the order of:

     __sortvalue__ == self.value.

Cheers,
    Ron





-- 
http://mail.python.org/mailman/listinfo/python-list
[prev in list] [next in list] [prev in thread] [next in thread]