Если бы памяти не было мало, как бы вы реализовали сортировку на языке с библиотеками для представления и сортировки наборов? - PullRequest
1 голос
/ 11 июня 2010

Если бы не было недостатка памяти, как бы вы реализовали сортировку на языке с библиотеками для представления и сортировки наборов

Ответы [ 2 ]

1 голос
/ 14 июля 2011

Это очень сильно зависит от ситуации. Я собираюсь предположить, что вы имели в виду список, а не набор. А также, насколько скудна память.

В любом случае, прочитайте это http://en.wikipedia.org/wiki/Sorting_algorithm#Summaries_of_popular_sorting_algorithms

Во всех случаях сортировка по месту слияния не будет плохой. http://en.wikipedia.org/wiki/Merge_sort Этот тип не использует порядок дополнительной памяти при сортировке

Быстрая сортировка часто лучше, если память не , что мало. http://en.wikipedia.org/wiki/Quicksort

А затем сортировка Bucket и Radix очень хорошо работает с определенными типами данных. То есть. если ваши числа меньше 10000, эти виды работают очень хорошо.

Они работают хуже при слишком большом наборе номеров. (т. е. случайные 32-битные целые). http://en.wikipedia.org/wiki/Bucket_sort http://en.wikipedia.org/wiki/Radix_sort

РЕДАКТИРОВАТЬ: Примечание: я проигнорировал целые библиотеки для представления и сортировки наборов. WTF это как-то связано? Может быть, этот вопрос ... если у меня есть библиотека для сортировки списков, которые могут иметь только один из каждого? Если это так, то вопрос слишком странный и звучит как домашнее задание.

1 голос
/ 11 июня 2010

Набор неупорядочен, поэтому сортировка наборов бесполезна. «Сортированный» набор такой же, как и сам набор, даже при нехватке памяти.

Представлять набор в не дефицитной памяти - это все равно, что представлять набор в дефицитной памяти. Однако если памяти недостаточно, мы могли бы создать двоичный предикат для каждого значения или объекта в памяти, заявив: «Я являюсь членом множества X».

Если вы хотите проверить, является ли объект Y членом множества X, просто проверьте двоичный предикат; это либо правда, либо ложь.

Итерация всех объектов в наборе похожа на массив. Он также может быть реализован как двойной связанный список или с использованием хеш-таблицы. Разница заключается в деталях; какие объекты вы хотите в наборе?

Если бы памяти не было мало, и у вас осталось достаточно мощности в вашем ЦП, то я бы сохранял каждое хеш-значение объекта в памяти, вместо этого вычисляя его на лету. Тогда реализация набора в стиле хэш-таблицы действительно быстра для перечисления возможностей. Добавление / удаление объектов из набора происходит довольно медленно.

Если добавление / удаление более необходимо, чем перечисление, подойдет любой связанный список.

Оба способа могут использовать значение предиката для каждого объекта. Это зависит от ваших требований; Например, вы разрешаете два объекта одновременно в двух наборах? (Обычно это «да»), тогда вам потребуется хранилище массивов / связанных списков для каждого объекта в наборе, чтобы хранить информацию о его членстве.

Хотя не существует "одного правильного" решения. Просто мои две копейки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...