In the average case (and practically), it really is constant access. But as the Big-O notation is about the worst case, so it's about constructing some obscure cases. Hash-based implementations often use buckets based on the result hash. The worst case would be, that all values have the same hash, so we basically end up with a plain list of values with the complexity of lists.
But this does not really apply to the practice and the implementations usually are very optimized, that it should be very hard to even construct such a case practically.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Isn't the amortized insertion/lookup/delete complexity for hash tables O(1)? But yeah you are right, it is more complicated.
In the average case (and practically), it really is constant access. But as the Big-O notation is about the worst case, so it's about constructing some obscure cases. Hash-based implementations often use buckets based on the result hash. The worst case would be, that all values have the same hash, so we basically end up with a plain list of values with the complexity of lists.
But this does not really apply to the practice and the implementations usually are very optimized, that it should be very hard to even construct such a case practically.