> Armin Rigo wrote: > ... > Unless there are serious objections I suggest to (i.e. I plan to) remove the > short-cut in PyObject_RichCompareBool() -- performance is probably not an > issue here -- and then review all built-in comparison methods and make sure > that they return "equal" for identical objects. I have a serious objection to this because it is a major performance problem. In my Python-2.3.3 code I had implemented an equivalent comparison test because of a performance bottleneck. The bottleneck involved looking up tuples in huge dictionaries of tuples (millions of tuples per dictionary). Putting in a simple equality test reduced the run time of programs by as much as 50%; since each program took days to run, this was a substantial improvement for me. I was considering posting this as a bugfix when I discovered that it had already been incorporated into the CVS. For the sake of people such as myself who use Python to perform large-scale symbolic processing, please consider other approaches to solving the NaN situation before removing this code. :s Robert H. Ledwith INET: rledwith at cas.org :s Unless explicitly stated to the contrary, nothing in this posting should :s be construed as representing my employer's opinions.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4