Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
booby, спасибо за разъяснения, теперь понял. Не вижу принципиальной разницы с моим способом попарного слияния. У свечи за один раз берутся два крайних подмассива и сливаются в один, затем следующая пара и т.д., у меня берутся два смежных, затем следующие два и т.д. В итоге количество слияний одинаково в обоих алгоритмах. В моем случае будет так Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 08:43 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Dima T, ну, с тем "упрощенным для понимания" вариантом, который был показан, наверно, нет разницы. В некотором отношении (локальности) твой "даже лучше" и "естественнее". В качестве разницы (между свечкой в Кнутовой записи и в показанном варианте): У Кнута свеча беспощадна к кэшу и чихать хотела на все представления о локальности разом. Она смотрит одновременно на обе стороны и копирует рассматриваемый элемент в нужную сторону немедленно и сразу, как только понимает, что условие сохранения непрерывности последовательностивыполняется. Слияние совмещено с выявлением последовательности. Писателю показанного варианта, очевидно поклоннику Вирта и Дейкстры, кто-то сказал, что это Содом и Гоморра - читать массив с двух концов одновременно . Поэтому он, на голубом глазу, предпочитает Ад и Израиль двойного касания к каждому элементу - первый раз а выявлении непрерывной цепочки, а второй - на фазе самого мерджа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 11:28 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
booby..... Но, если их переставлять не глядя, то нарушится стабильность, присущая исходному merge sort. Поэтому фига из трех пальцев - либо плюнуть на стабильность, либо плюнуть на разборки - кто из них длиннее, либо озаботиться устабилизацией обмена диапазонов. Если честно - опция стабильности мне всегда казалась очень странным требованием. Есть собственно KEY сортировки. И есть VALUE. Если очень важна стабильность ключей на выходе алгоритма (а именно - сохранение ПОРЯДКА) то можно сразу предложить добавить к ключу суррогат вида sequence (SEQ-KEY) и сортировать как обычно уже уникальный набор tuples вида {KEY, SEQ-KEY} любым нестабильным алгоритмом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 23:11 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Могу обоснованно предположить, что стабильная сортировка эффективнее, т.к.: 1. Не требует памяти для добавления суррогатных ключей; 2. Не требует времени на генерацию и вставку суррогатных ключей; 3. Не требует времени на удаление суррогатных ключей; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 07:55 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
2 Basil A. Sidorov, требование стабильности более строгое. Нечто, что должно быть доказанным или специально отслеженным. Поэтому, не глядя за кулисы - можно сразу сказать, что при прочих равных нестабильный алгоритм в среднем быстрее. И, тем самым, если под эффективностью понимать скорость сортировки - эффективнее. 2 mayton сортировка - просто один из алгоритмов, который может использоваться сам по себе, а может использоваться как фрагмент в цепочке алгоритмов, несущий вспомогательную функцию. Во втором случае стабильность может быть желательна или строго необходима. Пусть например, у тебя есть массив записей, хранящий страну происхождения, товар - яблоки или груши и цена товара. Массив уже сортирован по стране происхождения и цене товара. Пусть задается вопрос а какая максимальная цена среди всех яблок Логика ответа такова - надо сгруппировать по товару, отбирая только яблоки, а потом среди отобранных яблок найти максимальную цену. Для реализации группировки часто используют сортирующий алгоритм. И, если этот алгоритм стабильный, то вторая сортировка по цене на отобранном наборе не потребуется. В некоторых историях стабильность может оказаться ключевым свойством ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 13:38 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
boobyтребование стабильности более строгое. Нечто, что должно быть доказанным или специально отслеженным.Только предлагается немного другое: "Давайте забъём на стабильность, а если понадобится - сгородим огород, чтобы продолжать использовать нестабильную сортировку".Поэтому, не глядя за кулисы - можно сразу сказать, что при прочих равных нестабильный алгоритм в среднем быстрее.Стабильная сортировка "следит", чтобы ключи с одинаковыми значениями никак не переставлялись. Теоретически, наверное, возможно, но практически, всё-таки, маловероятно, что пред- и постобработка массива ключей для обеспечения стабильной сортировки нестабильным алгоритмом будет дешевле. Тем более - существенно дешевле. Поэтому надо использовать бритву Оккама, чтобы отсекать ненужные фантазии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 13:49 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Замер выше 20170548 std::stable_sort() делает в разы больше копирований чем std::sort(). ИМХО выгоднее в условие сравнения добавить доп. параметры, чем стабильную сортировку использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 14:14 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Dima TЗамер выше 20170548 std::stable_sort() делает в разы больше копирований чем std::sort(). ИМХО выгоднее в условие сравнения добавить доп. параметры, чем стабильную сортировку использовать. чудес не бывает, сравнение по доппараметрам 1. увеличит сложность операции сравнения 2. потребует больше действий (сравнений и перестановок) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 14:33 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovПоэтому, не глядя за кулисы - можно сразу сказать, что при прочих равных нестабильный алгоритм в среднем быстрее.Стабильная сортировка "следит", чтобы ключи с одинаковыми значениями никак не переставлялись. Теоретически, наверное, возможно, но практически, всё-таки, маловероятно, что пред- и постобработка массива ключей для обеспечения стабильной сортировки нестабильным алгоритмом будет дешевле. Тем более - существенно дешевле. Поэтому надо использовать бритву Оккама, чтобы отсекать ненужные фантазии. Простой пример 2 1 , 5 2 , 2 3 , 5 4 , 2 5 нестабильной сортируется в 1 перестановку 5 2 <=> 2 5 2 1 , 2 5 , 2 3 , 5 4 , 5 2 а стабильной минимум 3 перестановки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 14:34 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Dima T2 1 , 5 2 , 2 3 , 5 4 , 2 5 нестабильной сортируется в 1 перестановку 5 2 <=> 2 5 2 1 , 2 5 , 2 3 , 5 4 , 5 2 а стабильной минимум 3 перестановкиЭто всё замечательно и демонстрирует, что стабильная сортировка медленнее нестабильной. Где демонстрация того, что "нестабильная сортировка с наворотами для стабилизации" быстрее "изначально стабильной"? Даже не "существенно быстрее", а просто "быстрее"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 15:12 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, что за чепуха? Из какой ноздри взято взято утверждение, что нестабильная сортировка после стабилизации должна оказаться быстрее изначально стабильной? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 15:45 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
boobyИз какой ноздри взято взято утверждение, что нестабильная сортировка после стабилизации должна оказаться быстрее изначально стабильной?А теперь задайте этот вопрос mayton, который предложил стабилизировать нестабильный алгоритм путём предобработки массива ключей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:10 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovDima T2 1 , 5 2 , 2 3 , 5 4 , 2 5 нестабильной сортируется в 1 перестановку 5 2 <=> 2 5 2 1 , 2 5 , 2 3 , 5 4 , 5 2 а стабильной минимум 3 перестановкиЭто всё замечательно и демонстрирует, что стабильная сортировка медленнее нестабильной. Где демонстрация того, что "нестабильная сортировка с наворотами для стабилизации" быстрее "изначально стабильной"? Даже не "существенно быстрее", а просто "быстрее"? Что туть доказывать? Давай возьмем любой запрос к БД. Код: plaintext 1. Т.е. сортировка обычно требуется далеко не по всем полям. Как по твоему: повлияет сохранение исходного порядка f4,f5 на скорость сортировки? Чудес не бывает, дополнительные условия всегда усложняют алгоритм, поэтому замедляют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:18 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
ИМХО спор ни о чем. Хочешь порядок сохранить, замени компаратор с Код: plaintext 1. на Код: plaintext 1. Итоги: первый вариант АлгоритмЗаполнениеВремяКопированийСравненийstd::sort()31243041388831497425std::sort()43381177819576052std::sort()222186893017163848std::sort()51054000365900094std::sort()62082499706275071std::sort()723186939017164149std::sort()826518676419651458std::sort()9802945359733074653std::sort()101082604439427351506 второй АлгоритмЗаполнениеВремяКопированийСравненийstd::sort()31843053368031651345std::sort()41377662564248232380std::sort()220186893017163848std::sort()51198029388549573530std::sort()61268202191750400898std::sort()722186941017164162std::sort()825518676419651458std::sort()9693162457434261072std::sort()101283188979631212294 std::stable_sort() с первым компаратором АлгоритмЗаполнениеВремяКопированийСравненийstd::stable_sort()31432518690223635522std::stable_sort()4702511565123568259std::stable_sort()234169375009533052std::stable_sort()5482405000022654542std::stable_sort()6492463750022486292std::stable_sort()735169378509533222std::stable_sort()842329375008353742std::stable_sort()9361743807010629112std::stable_sort()10982518468123644316 Извиняюсь, красоту лень наводить, заполнение: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:47 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovboobyИз какой ноздри взято взято утверждение, что нестабильная сортировка после стабилизации должна оказаться быстрее изначально стабильной?А теперь задайте этот вопрос mayton, который предложил стабилизировать нестабильный алгоритм путём предобработки массива ключей. Бог с вами друзья. Я просто добавил что не вижу смысла стабилизировать ключи. Сами посудите. В реляционной алгебре нет вообще такого понятия. Если нужны доп-критерии порядка то добавляют синтетический уникальный ключ к неуникальному. А в не-реляционных юзкейсах (csv, Streams) - очень трудно придумать полезный и такой чтобы был серъезно аргументирован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 18:17 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
maytonА в не-реляционных юзкейсах (csv, Streams) - очень трудно придумать полезный и такой чтобы был серъезно аргументирован.Ограниченность используемого инструмента, например. Если всё, что у меня есть, это "sort /+номер", то отсортировать сначала по колонке +50, а уже потом - колонке +20 можно только двумя последовательными сортировками. P.S. "Есть много, друг Горацио ..." P.P.S. Если бы чистая реляционная алгебра была практичной - хинтов и прочей магии не существовало бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 19:27 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
mayton, (Хоть я тебя и понял правильно) Что ты говоришь? Если в реляционной алгебре нет такого понятия ( а в ней нет такого понятия), как это обстоятельство может быть изменено путем добавления чего-то к кому-то. Как не было понятия, так и взяться ему неоткуда. Эту алгебру порядок не интересует, она на первый-второй ничего и никого не рассчитывает. Уникальный ключ - он в огороде реляционной алгебры, а порядок - в Киеве, на стороне клиентского приложения, привносящего порядок в последовательность поступающих с огорода уникальных ключей. Так вот если на стороне того клиента используется набор последовательно выполняемых алгоритмов, как-то фильтрующих группирующих поступающие ключи и ставящих поступившие ключи в различные очереди для последующей обработки, и ставится задача сохранения историчности формирующихся очередей в том смысле, что ключ поступивший на обработку в такую систему в результирующей очереди должен оказаться перед ключём, пришедшим в систему позже, то необходимо использовать стабильную сортировку на промежуточных этапах. Утверждение сорта я добавлю второй ключ в сортировку и она станет стабильной эквивалентно тому, что промежуточный сортирующий алгоритм уже точно знает окончательную судьбу обрабатываемого ключа. Кроме разбора ключей в Киеве, стабильная сортировка часто считается желательной при работе с визуальными интерфейсами. Логическая организация системы, в которой эффект двухключевой сортировки достигается методом применения стабильной сортировки по второму ключу к набору данных, про который достоверно известно, что по первому ключу он уже сортирован, много проще в общем случае. Да и в смысле физического времени отклика у нее есть хорошие шансы против пересортировки заново по всему набору ключей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 01:19 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
booby, у меня нет с вами предмета спора. Я просто хотел акцентировать на том что никогда не видел смысла в стабилизации и не было у меня задач где сама постановка "порядка поступления на вход" данных была бы ключевой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 15:52 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
mayton, у меня тоже нет. Это не было спором. Это было попыткой пояснить, что что для специальных случаев могут лучше подходить специальные решения, в противоположность приспособления общего. И, в том, месте, когда и где алгоритму сортировки оказывается естественным образом присуща характеристика стабильности, его есть смысл не отбрасывать, а отложить на полку стабильных алгоритмов, в отличии от полки, где собираются нестабильные. С тем, чтобы при случае, может быть, иметь возможность выбрать из готовых стабильных, вместо того, чтобы заниматься стабилизацией нестабильного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 16:28 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
mayton, Потерпи меня еще минуту. Еще одно замечание, касательное специальных собственных характеристик алгоритмов сортировки, может быть полезных в специальных частных случаях. Вот пирамидальная сортировка, которой ты формально посвятил тему: - неустойчива, так же как и быстрая - для "среднего случая" оценивается как несколько хуже быстрой при той же асимптотике. Но. У этой сортировки есть еще одно собственное свойство, кроме нестабильности - это сортировка с использованием специальной сортирующей структуры. Хуже быстрой в среднем она оказывается в динамическом случае, когда сортирующую пирамиду приходится строить по мере поступления сортируемых данных. Однако, если представить себе статический случай, когда состав пирамиды (сортирующей структуры) известен до начала процедуры сортировки, то пирамидальная сортировка может волшебным образом превращаться из алгоритма, работающего за O(n*log(n)) в алгоритм, работающий за O(n). Т.е. для специальных "статических" случаев сортировка с использованием полной сортирующей структуры (в качестве которой, в простейшем случае, может быть использован даже сам однажды сортированный массив в комбинации с разумно подкрученным бинарным поиском, если известно, что состав сортируемых данных всегда один и тот же) может достаточно далеко обгонять любые лидирующие для динамического случаи алгоритмы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 17:14 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovP.P.S. Если бы чистая реляционная алгебра была практичной - хинтов и прочей магии не существовало бы. Индексы это уже магия, в теории РСУБД они не упоминаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 20:43 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
boobymayton, Потерпи меня еще минуту. Еще одно замечание, касательное специальных собственных характеристик алгоритмов сортировки, может быть полезных в специальных частных случаях. Вот пирамидальная сортировка, которой ты формально посвятил тему: неустойчива, так же как и быстрая - для "среднего случая" оценивается как несколько хуже быстрой при той же асимптотике. Но. У этой сортировки есть еще одно собственное свойство, кроме нестабильности - это сортировка с использованием специальной сортирующей структуры. Хуже быстрой в среднем она оказывается в динамическом случае, когда сортирующую пирамиду приходится строить по мере поступления сортируемых данных. Однако, если представить себе статический случай, когда состав пирамиды (сортирующей структуры) известен до начала процедуры сортировки, то пирамидальная сортировка может волшебным образом превращаться из алгоритма, работающего за O(n*log(n)) в алгоритм, работающий за O(n). Т.е. для специальных "статических" случаев сортировка с использованием полной сортирующей структуры (в качестве которой, в простейшем случае, может быть использован даже сам однажды сортированный массив в комбинации с разумно подкрученным бинарным поиском, если известно, что состав сортируемых данных всегда один и тот же) может достаточно далеко обгонять любые лидирующие для динамического случаи алгоритмы Не могли бы вы пожалуйста привести пример так называемых вами специальных статических случаев?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 22:13 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
SashaMercury ... Не могли бы вы пожалуйста привести пример так называемых вами специальных статических случаев?) о статическом случае можно рассуждать всякий раз, когда известно, что на времени обработки полное множество данных не меняется, а число поступающих для сортировки серий, каждая из которых представляет собой подмножество полного множества данных, достаточно велико, чтобы оправдать создание сортирующей структуры на полном множестве, которую потом можно использовать для сортировки набора поступающих подмножеств. Возможно, самый распространенный пример "статического случая" - индексы в базе данных. Чем компактнее индексируемый набор данных и чаще поступают запросы на выборку упорядоченного подмножества данных или поиск минимального/максимального или предшествующих им элементов, тем больше смысла в создании такой сортирующей структуры (она же выбирающая), как индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2017, 23:46 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
boobymayton, Вот пирамидальная сортировка, которой ты формально посвятил тему: - неустойчива, так же как и быстрая - для "среднего случая" оценивается как несколько хуже быстрой при той же асимптотике. Но. У этой сортировки есть еще одно собственное свойство, кроме нестабильности - это сортировка с использованием специальной сортирующей структуры. Это скорее не сортировка с использование структуры данных, в сортировка основанная на использование удачной структуры данных. В данном конкретном случае, исторически есть смысл ссылаться на сортировку выбором и оптимизацию выбора нового минимального элемента не за счет поиска по всему массиву за O(n) итераций, использование удачной структуры данных и дает нам в итоге(это ключевые слова) O(lgn) на поиск нового элемента. Потому это сортировка появившаяся только благодаря удачной и красивейшей структуре данных - пирамиды. boobyо статическом случае можно рассуждать всякий раз, когда известно, что на времени обработки полное множество данных не меняется, а число поступающих для сортировки серий, каждая из которых представляет собой подмножество полного множества данных, достаточно велико, чтобы оправдать создание сортирующей структуры на полном множестве, которую потом можно использовать для сортировки набора поступающих подмножеств. Возможно, самый распространенный пример "статического случая" - индексы в базе данных. Чем компактнее индексируемый набор данных и чаще поступают запросы на выборку упорядоченного подмножества данных или поиск минимального/максимального или предшествующих им элементов, тем больше смысла в создании такой сортирующей структуры (она же выбирающая), как индекс. Я понимаю то, о чем говорил White Owl - действительно, существуют различные вариации пирамидальной сортировки и т.д. и т.п. Но то, о чем говорите вы, мне не очень понятно. Если вас это не слишком затруднит, приведите пожалуйста конкретный набор данных, конкретную серию и какая именно сортировка выполняется. Возможно вы имеете что-то другое, и я вас просто не понимаю, поскольку у пирамидальной сортировки в классическом понимании есть хорошая оценка асимптотики независимо от каких либо случаев: "худший", "лучший","средний". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 22:33 |
|
||
|
Тяпничная пирамида
|
|||
|---|---|---|---|
|
#18+
SashaMercury Возможно вы имеете что-то другое, и я вас просто не понимаю, поскольку у пирамидальной сортировки в классическом понимании есть хорошая оценка асимптотики независимо от каких либо случаев: "худший", "лучший","средний". booby, тоже удивило, хоть упрись но у классической реализации "составление кучи O(N), вычленение O(N ln(n))" практически стабильное время - это один из её плюсов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2017, 08:06 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=39398655&tid=2018242]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 173ms |

| 0 / 0 |
