Как построение кучи может быть o (n) временной сложностью?

я думаю, что в этой теме есть несколько вопросов:

• как вы реализуете buildHeap, чтобы он работал в O (n) времени?
• как вы показываете, что buildHeap работает в O (n) время при правильной реализации?
• почему эта же логика не работает, чтобы выполнить сортировку кучи в O (n) времени, а не O (N log n)?

часто, ответы на эти вопросы внимания о разнице между siftUp и siftDown. Правильный выбор между siftUp и siftDown важно получить O (n) производительность buildHeap, но ничего не делает, чтобы помочь понять разницу между buildHeap и heapSort в целом. Действительно, правильные реализации обоих buildHeap и heapSort будет только использовать siftDown. The siftUp операция необходима только для выполнения вставок в существующую кучу, поэтому она будет использоваться для реализации приоритета например, очередь с использованием двоичной кучи.

я написал это, чтобы описать, как максимум куча работы. Это тип кучи, обычно используемый для сортировки кучи или для очереди приоритетов, где более высокие значения указывают на более высокий приоритет. Также полезна минимальная куча; например, при получении элементов с целочисленными ключами в порядке возрастания или строк в алфавитном порядке. Принципы точно такие же, просто изменить порядок сортировки.

на куча собственность указывает, что каждый узел в двоичной куче должен быть по крайней мере таким же большим, как оба его дочерних узла. В частности, это означает, что самый большой элемент в куче находится в корне. Просеивание вниз и просеивание вверх-это, по сути, одна и та же операция в противоположных направлениях: переместить узел-нарушитель, пока он не удовлетворит свойству кучи:

• siftDown меняет местами слишком маленький узел с его самым большим дочерним узлом (тем самым перемещая его вниз), пока он не станет по крайней мере таким же большим, как оба узла ниже него.
• siftUp обменивает узел, который слишком велик с его родителем (тем самым перемещая его вверх), пока он не будет не больше, чем узел над ним.

количество операций, необходимых для siftDown и siftUp пропорциональна расстоянию узел мог двигаться. Для siftDown, это расстояние от нижней части дерева, так siftDown дорого для узлов в верхней части дерева. С siftUp, работа пропорциональна расстоянию от вершины дерева, поэтому siftUp дорого для узлов в нижней части дерева. Хотя обе операции O (log n) в худшем случае в куче только один узел находится вверху, тогда как половина узлов лежит в нижнем слое. Так что не должно быть слишком удивительно, что если мы должны применить операцию к каждому узлу, мы предпочли бы siftDown над siftUp.

на buildHeap функция принимает массив несортированных элементов и перемещает их, пока все они не удовлетворяют свойству кучи, таким образом, создается допустимая куча. Есть два подхода, которые можно принять за buildHeap С помощью siftUp и siftDown операции, которые мы описали.

1. начните с верхней части кучи (начало массива) и вызовите siftUp по каждому пункту. На каждом шаге ранее просеянные элементы (элементы перед текущим элементом в массиве) образуют допустимую кучу, и просеивание следующего элемента помещает его в допустимую позицию в куче. После просеивания каждого узла все элементы удовлетворяют свойству кучи.

2. или идите в противоположном направлении: начните с конца массива и двигайтесь назад к фронту. На каждой итерации вы просеиваете элемент вниз, пока он не окажется в правильном месте.

оба этих решения создадут допустимую кучу. Вопрос в том, какая реализация для buildHeap эффективнее? Неудивительно, что это вторая операция, которая использует siftDown.

давайте h = log n определить высоту кучи. Работа, необходимая для siftDown подход задается суммой

(0 * n/2) + (1 * n/4) + (2 * n/8) + ... + (h * 1).

каждый член в сумме имеет максимальное расстояние, которое узел на данной высоте должен будет переместить (ноль для нижнего слоя, h для корня), умноженное на количество узлов на этой высоте. Напротив, сумма для вызова siftUp на каждый узел

(h * n/2) + ((h-1) * n/4) + ((h-2)*n/8) + ... + (0 * 1).

это должно быть ясно, что вторая сумма больше. Только первый срок is hn / 2 = 1/2 N log n, так что этот подход имеет сложность в лучшем случае O (N log n). Но как мы докажем, что сумма siftDown подход действительно O (n)? Один из методов (есть и другие анализы, которые также работают) - превратить конечную сумму в бесконечный ряд, а затем использовать ряд Тейлора. Мы можем игнорировать первый член, который равен нулю:

если вы не уверены, почему каждый из этих шагов работает, вот обоснование процесса в словах:

• все члены положительны, поэтому конечная сумма должна быть меньше бесконечной суммы.
• серия равна серии мощности, оцениваемой в x=1/2.
• этот степенной ряд равен (постоянное время) производной ряда Тейлора для f(x)=1/(1-x).
• x=1/2 находится в интервале сходимости этого Тейлора серии.
• таким образом, мы можем заменить ряд Тейлора с 1/(1-x), дифференцировать и оценивать, чтобы найти значение бесконечного ряда.

так как бесконечная сумма точно n, мы заключаем, что конечная сумма не больше и, следовательно,O (n).

следующий вопрос: если можно запустить buildHeap в линейное время, почему сортировка кучи требует O (N log n) времени? Ну, сортировка кучи состоит из двух этапов. Во-первых, мы называем buildHeap на массиве, который требует O (n) время, если реализован оптимально. Следующий этап-повторно удалить самый большой элемент в куче и поместить его в конец массива. Поскольку мы удаляем элемент из кучи, всегда есть открытое место сразу после конца кучи, где мы можем сохранить элемент. Таким образом, сортировка кучи достигает отсортированного порядка, последовательно удаляя следующий по величине элемент и помещая его в массив начиная с последней позиции и двигаться вперед. Именно сложность этой последней части доминирует в сортировке кучи. Петля выглядит так:

for (i = n - 1; i > 0; i--) {
    arr[i] = deleteMax();
}

ясно, что цикл выполняется O (n) раз (n-1 если быть точным, последний пункт уже на месте). Сложность deleteMax для кучи O (log n). Обычно он реализуется путем удаления корня (самого большого элемента, оставшегося в куче) и замены его последним элементом в куче, который является листом, и, следовательно, одним из самых маленьких предметов. Этот новый корень почти наверняка нарушит свойство кучи, поэтому вам нужно вызвать siftDown пока вы не переместите его обратно в приемлемом положении. Это также имеет эффект перемещения следующего по величине элемента до корня. Обратите внимание, что, в отличие от buildHeap где для большинства узлов мы называем siftDown из нижней части дерева, мы назвали siftDown С вершины дерева на каждой итерации! хотя дерево сокращаясь, он не сжимается достаточно быстро: высота дерева остается постоянной, пока вы не удалите первую половину узлов (когда вы полностью очистите нижний слой). Тогда для следующей четверти высота h-1. Таким образом, общая работа для этого второго этапа

h*n/2 + (h-1)*n/4 + ... + 0 * 1.

обратите внимание на переключатель: теперь нулевой рабочий случай соответствует одному узлу и h рабочий случай соответствует половине узлов. Эта сумма O (N log n) как неэффективные версии buildHeap это реализовано с помощью siftUp. Но в этом случае у нас нет выбора, так как мы пытаемся сортировать, и мы требуем, чтобы следующий по величине элемент был удален следующим.

в общем, работа для сортировки кучи-это сумма двух этапов:O (n) время для buildHeap и о(n записей N), чтобы удалить каждый узел в порядке, поэтому сложность O (N log n). Вы можете доказать (используя некоторые идеи из теории информации), что для сортировка на основе сравнения,O (N log n) это лучшее, на что вы могли бы надеяться в любом случае, поэтому нет причин разочаровываться в этом или ожидать, что сортировка кучи достигнет o(n) привязки по времени, что buildHeap делает.