4 ms·
I dunno, how efficient is this?
by Jenz 7y ago
I dunno, how efficient is this?
- coldtea 7y agoSo efficient that nobody really cared about or mentioned it all those decades, so there's that...
- zsrxx 7y agoIt's Python, it's not like anybody is going to complain about performance, because nobody expects any.
- mkl 7y agoMany people complain about performance, and enormous amounts of effort have been spent on improving it, successfully. People do expect good performance, and can achieve it in many useful cases.
- fernandotakai 7y agoi mean, if you are worried about python's rounding number performance, you are probably using numpy already (which has a different implementation that is faster).
- Shorel 7y agoI used to complain about performance, as I remember the abysmally bad performance of Zope (Python web framework) back in 2003 -2004. It made me write off that language for about a decade. Benchmarking Python3 code reveals that there have been some quite noticeable improvements.
- coldtea 7y agoIf this implementation was a bottleneck in anything, people would have complained, as they have in other areas in Python. There are performance improvements in places people complain about all the time. Besides you missed the part where this is used in other speed-critical places, like protobuf, the K&P implementation, etc.
- ThePadawan 7y agoI agree - my takeaway is "float-to-string and string-to-float conversion is probably faster than I thought"
- ben509 7y agoCompared to base=10^places, multiply, truncate, divide? Horriby inefficient.
- dagw 7y agoSure, but their approach is on the other hand more correct. All numerical code reaches a point where you have to balance performance vs. correctness, and here cpython has chosen correctness over speed.
- ben509 7y agoThey're creating a sequence of digits and then truncating. If you want to replicate that precisely, you could use an accumulator and a loop to do the same thing. At least then you could break early.
- ben509 7y agoIt's slower than native python. %timeit round(12335423552.33, -6) %timeit int(12335423552.33 / 1_000_000.0) * 1_000_000.0 500 ns ± 3.88 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) 219 ns ± 1.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
- dagw 7y agoWell obviously the approach round() takes is slower than the naive approach. The whole point of doing it the way round() does it is that it gives the correct answer in cases where the naive approach fails.