Для меня имеет смысл, что это ускоряет решение проблемы, если две половины занимают меньше половины работы над всем набором данных.
Это не суть алгоритмов «разделяй и властвуй». Обычно дело в том, что алгоритмы не могут «иметь дело со всем набором данных» вообще. Вместо этого он разбивается на части, которые тривиально решить (например, сортировка двух чисел), затем они решаются тривиально, а результаты объединяются таким образом, чтобы получить решение для полного набора данных.
Но почему бы не разбить набор данных на три части? Четыре? п?
Главным образом потому, что разбиение его на более чем две части и рекомбинация более двух результатов приводит к более сложной реализации, но не меняет фундаментальную (Big O) характеристику алгоритма - разница является постоянным фактором и может привести к замедлению если деление и рекомбинация более чем двух подмножеств создает дополнительные издержки.
Например, если вы выполняете трехстороннюю сортировку слиянием, то на этапе рекомбинации вы должны найти самый большой из 3 элементов для каждого элемента, который требует 2 сравнений вместо 1, так что вы сделаете в два раза больше сравнений в целом , Взамен вы уменьшаете глубину рекурсии на коэффициент ln (2) / ln (3) == 0,63, поэтому у вас на 37% меньше свопов, но на 2 * 0,63 == 26% больше сравнений (и обращений к памяти). Хорошо это или плохо, зависит от того, какое оборудование дороже.
Я также видел много ссылок на трехстороннюю быструю сортировку. Когда это быстрее?
Очевидно, что вариант быстрой сортировки с двумя опорными точками может потребовать такого же количества сравнений, но в среднем на 20% меньше свопов, так что это чистый выигрыш.
Что используется на практике?
В наши дни почти никто не программирует свои собственные алгоритмы сортировки; они используют один предоставленный библиотекой. Например, API Java 7 на самом деле использует быструю сортировку с двойным поворотом.
Люди, которые на самом деле по какой-то причине программируют собственный алгоритм сортировки, будут склонны придерживаться простого двухстороннего варианта, поскольку меньшая вероятность ошибок в большинстве случаев превышает производительность на 20%. Помните: безусловно самое важное улучшение производительности - это когда код переходит от «не работает» к «работает».