4 ms·
See, that would violate the standard. The standard mandates O(n log n), but I don't think any implementation follows this. (Again, that complexity is indeed pos
by wfunction 12y ago
See, that would violate the standard. The standard mandates O(n log n), but I don't think any implementation follows this. (Again, that complexity is indeed possible, but quite challenging and not something I've seen in standard library implementations.)
- CJefferson 12y agoNo, my previous message was a quote from the standard. O(n log^2 n) is fine when no extra memory is available. As you say, this could in principle now be tightened. In the past the standard used to allow O(n^2) std::sort to permit naive quicksort implementations, which has now been tightened to O(n log n). Here's the relevant quote from stable_sort: > Complexity: It does at most N log^2(N) (where N == last - first) comparisons; if enough extra memory is available, it is N log(N).
- wfunction 12y agoOhh sorry, I thought you were talking about the merge, not the sort. Yes O(n log n) is allowed for the merge, but what I'm saying is that the Dr. Dobbs article's in-place merge sort is actually not quite an in-place variant of merge sort: its complexity (as far as I can tell) is O(n log^2 n) rather than O(n log n).