Rendered at 18:27:25 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
alexpotato 7 hours ago [-]
Dave Beazley has a great talk about using Python built ins [0] for data analysis and other quick operations.
As a meta note, I've used many of these builtins over the years but, due to LLMs, have been using them less and less. Re-watching the video almost felt like watching bushcrafters make a chair using just a knife and saw...
Isn't O(n - k) or O(len(l1) + len(l2)) just O(n)? Instead of blurring the line between complexity-analysis and cycle-counting, just print both the complexity and the est proportional cycle-count as separate measures.
IsTom 28 minutes ago [-]
If k = n - constant it comes out to O(1).
mwkaufma 28 minutes ago [-]
Every O(n) is O(1) if n = 1. Complexity measures worst-case by-definition, not all cases.
IsTom 21 minutes ago [-]
It has two parameters and depending on their relation it will act differently, it's reasonable to include this information. It is worst case O(1) when n and k don't differ much.
mwkaufma 14 minutes ago [-]
You've introduced an idiosyncratic definition of "worst-case" that nobody else uses to redefine proportional cycle-counting as "complexity", so yeah, I guess in your novel terminology that makes sense, but it isn't consistent with any CS textbook.
StellarScience 3 hours ago [-]
Python is famously built around hash tables. So much so that several versions ago they made an improvement to the hash table implementation, and the entire language became several percent faster.
However, I'm surprised to see no data structures at all with O(log(N)) complexity. Surely there are some use cases for which that's desirable?
krautsauer 1 hours ago [-]
One reason you don't see a data structure with O(log(n)) operations in this list is that priority queues/heaps are not a built-in type. Weirdly, there isn't a type for them at all, just a bunch of functions (good luck if you use them wrong). https://docs.python.org/3/library/heapq.html
`x in range(n)` is already optimized, but that was easier since the `__contains__` method already existed, but an equivalent `__min__` or `__max__` does not.
dist-epoch 6 hours ago [-]
> Basically you are just asking for one of the parameters it was created with.
See, you already made a mistake:
>>> min(range(10, 1, -3))
4
4 is neither the min or max of the range (their actual names are start and stop), and notice how the max is the first argument and the min is the second argument
Of course, the actual implementation of constant time min/max on range would be trivial.
d0mine 17 minutes ago [-]
4 is the min of the range (stop (1 here) is never included (by definition. Ask Dijkstra why))
gpugreg 7 hours ago [-]
Notable pitfalls:
- s[i:j] is O(j - i) because it creates a copy instead of a view
- max(range(n)) is O(n)
- substring search is O(n), which is good, but rfind is O(n m)
- iterative string concatenation (for c in ...: s += c) can be O(n^2) due to string immutability according to footnote 10, although it is O(n) in most cases due to an implementation detail of CPython: https://stackoverflow.com/a/34008199
chronial 49 minutes ago [-]
Note the footnote for rfind:
> This is the worst case. Reverse searches are O(n) on typical input.
emil-lp 4 hours ago [-]
They forgot to include GC overhead.
feelamee 3 hours ago [-]
how gc influence time complexity? elaborate, pks
slopinthebag 2 hours ago [-]
Maybe you need to factor in the GC algorithm when determining big O, since an algorithm which implements some complexity but creates a lot of garbage actually ends up with a worse big O?
Seems like a bit of a stretch to me but possible?
chubot 52 minutes ago [-]
It seems like that's pretty easy to disprove -- GC time is proportional to allocation time.
(allocation happens in the mutator, GC happens in the collector -- there is a symmetry)
The constant factor could be 500 or 50,000, but it's still proportional.
And allocations are some subset of the operations of the algorithm itself.
So then GC can't increase the overall time by more than a constant factor. So the big-O is the same.
(You could have some nuance on how to match GC operations to mutator operations, but the overall point is still true)
chubot 43 minutes ago [-]
[dead]
jjgreen 7 hours ago [-]
Nice page, but odd that they have O(...) in every row, surely that belongs in the column header
As a meta note, I've used many of these builtins over the years but, due to LLMs, have been using them less and less. Re-watching the video almost felt like watching bushcrafters make a chair using just a knife and saw...
0 - https://www.youtube.com/watch?v=lyDLAutA88s
However, I'm surprised to see no data structures at all with O(log(N)) complexity. Surely there are some use cases for which that's desirable?
I thought min and max where constants stored in the object. Basically you are just asking for one of the parameters it was created with.
https://github.com/python/cpython/issues/135824#issuecomment...
`x in range(n)` is already optimized, but that was easier since the `__contains__` method already existed, but an equivalent `__min__` or `__max__` does not.
See, you already made a mistake:
4 is neither the min or max of the range (their actual names are start and stop), and notice how the max is the first argument and the min is the second argumentOf course, the actual implementation of constant time min/max on range would be trivial.
- s[i:j] is O(j - i) because it creates a copy instead of a view
- max(range(n)) is O(n)
- substring search is O(n), which is good, but rfind is O(n m)
- iterative string concatenation (for c in ...: s += c) can be O(n^2) due to string immutability according to footnote 10, although it is O(n) in most cases due to an implementation detail of CPython: https://stackoverflow.com/a/34008199
> This is the worst case. Reverse searches are O(n) on typical input.
Seems like a bit of a stretch to me but possible?
(allocation happens in the mutator, GC happens in the collector -- there is a symmetry)
The constant factor could be 500 or 50,000, but it's still proportional.
And allocations are some subset of the operations of the algorithm itself.
So then GC can't increase the overall time by more than a constant factor. So the big-O is the same.
(You could have some nuance on how to match GC operations to mutator operations, but the overall point is still true)