Antoon Pardon wrote: > Op 2005-10-26, Ron Adam schreef <[EMAIL PROTECTED]>: > >>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