[tlahtinen]

I'm a programmer (after a fashion) but I don't know how quicksort works.

This is how I understand it after reading these instructiöns, without looking up any further explanation:

1. Choose a random element as the 'center' point of the sort

2. That element defines the maximum 'height' (value)

3. Anything that is larger than that value, is moved to the right side of the 'center'

4. Anything that is smaller than that value, is moved to the left side of the center. After this, the array is partially sorted.

5. The sorting process is repeated on both 'sides' independently, picking a new random center element and so on

What isn't clear, is how often the process needs to be repeated, or when the algorithm 'knows' that the sorting has been finished - surely it can't be just three iterations?

By now I've already looked up how the algorithm actually works, but the above is what I got out of the illustration :)

[klibertp]

Yeah, that's about it. Personally, I'm not sure I'd get this much out of the picture, but you can see the information is there.

> surely it can't be just three iterations?

To save others a search: you stop when the remaining sub-arrays are sorted by definition (ie. [] or [x]/size of 0 or 1).

[tialaramex]

Also, to save any further puzzling: In practice the very fast sort you use, even if it is labelled "Quicksort" probably doesn't actually do this "all the way down" even though that's the strict algorithm.

They'll have a highly optimised small sort and use that whenever sorting very small things. So e.g. IPN Sort the Rust stdlib unstable sort will do this for 16 items, even though for a big slice it'd quick sort them by default, once it's down to say 10 items they're going to the specialised small sort.

Any serious "fast" sort in 2025 will be a hybrid, using several of these classic sorting algortihms, plus other insights to produce the overall best solution to their problem on modern hardware.