Live data from Hacker News

On the Worst-Case Complexity of TimSort

drops.dagstuhl.de

51–60 of 78 posts

Re: On the Worst-Case Complexity of TimSort

#51
post #35
post #27

Earlier quoted context omitted.

I'd say it the other way around : 1/ it's amazing that a code that is used in countless occurences can still have a bug; 2/ (I've studied sorting algorithms for a while) finding such a bug is very clever... Kudo's to the authors.

It looks deceptively like it but 'kudos' is not plural of a kudo (or reference to some awesome thing Kudo once did).

Is it really not? The dictionary says otherwise, albeit by back-formation (as is the English way).

https://www.merriam-webster.com/dictionary/kudo

Re: On the Worst-Case Complexity of TimSort

#52
post #47
post #38

Earlier quoted context omitted.

No, worst-case complexity of real quicksort is always O(n^2), regardless of pivot choice strategy (even with stochastic pivot choice, although you’d have to get very unlucky to hit that worst case). You can make the average case better or worse though. The only way of making quicksort’s worst-case runtime O(n log n) is by limiting recursion depth, as done e.g. in introsort. But that’s no longer quicksort.

This is wrong. See https://en.m.wikipedia.org/wiki/Quicksort , section "Selection-based pivoting".

Non-mobile link:

https://en.wikipedia.org/wiki/Quicksort#Selection-based_pivo...

Re: On the Worst-Case Complexity of TimSort

#53
post #17

The linked java test file, http://igm.univ-mlv.fr/~pivoteau/Timsort/Test.java - still crashes the latest Java 10.0.2 with an 'Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 49'. Amazing! I wonder if this makes some web services vulnerable.. if the user can submit a just-so array of ints to be sorted? But it does seem like it would require uploading a really huge array (>4GB?)

Chances are you'll get an OutOfMemoryException first :)

The Java text file has a comment asking the user to allocate more memory for jvm.

Re: On the Worst-Case Complexity of TimSort

#54
post #50

Earlier quoted context omitted.

Crashing out of execution doesn't really seem like an actionable attack vector, unless that exception bubbles all the way to the application invocation.

Causing a crash is an excellent vector for a denial-of-service attack.

If you can make your service allocate 10G of memory, it's already a denial of service attack.

Re: On the Worst-Case Complexity of TimSort

#55

Amazing there is still something to find in a sort algorithm.

Especially when targeting realistic machine models, there are a lot of things that are suboptimal about the classical sorting algorithms like quicksort or mergesort. For example, a quicksort with perfect choice of pivot will incur a branch miss with probability 50% for every element. That's not something classical complexity analysis measures, but on actual CPUs, branch misses have quite an impact (something like 10–…

Out of curiosity, what do you read/follow that makes stuff like this discoverable?

Re: On the Worst-Case Complexity of TimSort

#56
post #44

Earlier quoted context omitted.

arrayToSort[sum] = 1; This is just blatant programmer error. The code is attempting to assign a value to a slot in an array of a fixed size, which does not exist. Use: Integer[] arrayToSort = new Integer[2000000000]; No error.

The equivalent Python code works fine, though. >>> a=[0]*sum(rls) >>> sum=-1 >>> for i in rls: ... sum += i ... a[sum] = 1 ... >>> a.sort() >>> Takes a real good while, too.

That's because the array to be sorted is packed and inflated, so as to be the worst possible input for that kind of sort.

Worst-case complexity.

Also, I needed to bump my JVM heap up to 16GB (not 9GB as recommended), just to run it.

Re: On the Worst-Case Complexity of TimSort

#57

Earlier quoted context omitted.

Especially when targeting realistic machine models, there are a lot of things that are suboptimal about the classical sorting algorithms like quicksort or mergesort. For example, a quicksort with perfect choice of pivot will incur a branch miss with probability 50% for every element. That's not something classical complexity analysis measures, but on actual CPUs, branch misses have quite an impact (something like 10–…

Out of curiosity, what do you read/follow that makes stuff like this discoverable?

I'm a PhD student in algorithmics / algorithm engineering, so I work with a lot of people who do stuff like this, even though my research isn't related to sorting. Super Scalar Sample Sort (which ips4o is based on) was co-authored by my advisor, Peter Sanders, and I re-implemented it a few years ago in modern C++ just for the fun of it. Turns out that was a lot nicer to read than the original code (which isn't public) and a bit faster, too. I put that on GitHub where the blockquicksort authors found it and contacted me and we traded some emails and made some improvements. Sometime later my advisor and two colleagues came up with an idea for in-place super-scalar sample sort, out of which eventually ips4o was born.

So, uh, I guess I just work with the right people :) Sorry that I can't give you anything concrete. All of these papers were presented at ESA (European Symposium on Algorithms), though, so that's a good venue to follow. But beware, ESA has a theory track that's a lot bigger than the experimental track, and papers published there can be somewhat unapproachable ;)

Re: On the Worst-Case Complexity of TimSort

#58

Earlier quoted context omitted.

Especially when targeting realistic machine models, there are a lot of things that are suboptimal about the classical sorting algorithms like quicksort or mergesort. For example, a quicksort with perfect choice of pivot will incur a branch miss with probability 50% for every element. That's not something classical complexity analysis measures, but on actual CPUs, branch misses have quite an impact (something like 10–…

Out of curiosity, what do you read/follow that makes stuff like this discoverable?

For people who aren't Ph.D. students, it may help to contact a local CS department and see what they have going on. There should at least be a grad student colloquium meeting once a week or so. I attended that at Penn a few times, although it was too far above me to really follow (lots of PL theory). More recently I've been going to a Database Reading Group at Portland State University (http://datalab.cs.pdx.edu/dbrg/index.php), which is a great way to get a taste of current research in that niche. Databases are less rarefied, too. :-)

Re: On the Worst-Case Complexity of TimSort

#59
post #50

Earlier quoted context omitted.

Crashing out of execution doesn't really seem like an actionable attack vector, unless that exception bubbles all the way to the application invocation.

Causing a crash is an excellent vector for a denial-of-service attack.

Usually unexpected exception results in a HTTP 500 response (or something similar) and few lines in the log. It does not result in stopped server.

Re: On the Worst-Case Complexity of TimSort

#60
post #43

Earlier quoted context omitted.

And in the best case (already sorted array), it's equal to 1 and the algorithm performs as O(n), which is nice to prove in one go. In some other typical cases (otherwise sorted array with one element inserted, two sorted arrays appended to each other) rho is 3 and 2, so also O(n).

All sorting algorithms can trivially be made to perform in O(n) in the "already sorted" scenario without worsening the worst case complexity, so that isn't really helpful.

It can be done only by adding an initial check that does only that. But this means that the algorithm speed doesn’t gradually increase with partially sorted sequences.

For instance, timsort is also very fast if only a single element is unsorted, or only two elements, or only three elements. These are not special cases explicitly handled, its just the natural way the algorithm works.

Post reply on HN