Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Найти N меньших элементов множества M
Форум на CrossPlatform.RU > Курилка > Алгоритмы, задачи по программированию, логические игры
ViGOur
Собственно задача в названиии: Найти N меньших элементов множества M, нужен наиболее быстрый алгоритм поиска

M может быть как 100, так и стремиться к бесконечности! :)

В множестве только числа, от 0 до X.

p.s. приводите свои варианты, не стесняйтесь!
FantasyOr
qSort
и берёшь N элементов с нужного края.
сделал бы именно так
ViGOur
По условию задачи количество элементов множества может стремиться к бесконечности, в таком случае сколько времени потратит qSort, на сортировку всего множества? И это получается, что для нахождения например 100 элементов, нужно будет отсортировать 2^1000000000000 элементов. Слишком большие затраты...
Алексей1153
1) если исходные данные изначально хранить в индексированном виде, то всё элементарно


2) (скрыл спойлером)

Раскрывающийся текст
ага! Не подглядывай;)если сортировка отпадает, то решение, по-моему, единственное: отсортированный массив результатов с максимальным размером N . Пробегая по исходным данным, нужно проверять, не оказался ли рассматриваемый элемент меньше всех, либо равный наименьшему в массиве результата. Если да - добавить его туда, выбросив самый большой элемент (сохраняя сортировку).

и так , пока не всё

(разумеется, в начале работы массив результатов пуст, потом по элементику растёт до N)
wiz29
самый надежный способ пройти перебором по всем элементам за 1 проход решится данная задача.

ну если доп данных каких то нет о структуре элементов или о законе их изменения и распределения)
ViGOur
Да, забыл сказать, что в множестве только числа, от 0 до X, и лежат они могу как случайны образом, так и упорядочено (смотри худший и лучший случай)

Какие еще нужны доп данные?
wiz29
из вышеуказанной постановки, при M->∞ задача за конечное время вряд ли решаема:)))

Цитата(ViGOur @ 23.1.2012, 17:56) *
Да, забыл сказать, что в множестве только числа, от 0 до X.

Какие еще нужны доп данные?


Х-конечное?
ViGOur
А что оно тебе даст? Я понимаю, что в случае 0 <= X <= 2 по сравнению с 0 <= X <= 1000 увеличится скорость алгоритма. Но нас то интересует, алгоритм, который будет универсален как для одного, так и для другого случая и так же быстр! :)

Цитата(wiz29 @ 23.1.2012, 17:57) *
из вышеуказанной постановки, при M->∞ задача за конечное время вряд ли решаема:)))
У нас под рукой супер пупер инопланетный сервак, который может посчитать ∞^∞ :D

Цитата(Алексей1153 @ 23.1.2012, 17:26) *
если исходные данные изначально хранить в индексированном виде, то всё элементарно
Ты снова забываешь о том, что у нас может быть огромное количество данных M, которые предназначены для того, чтобы из них получить N наименьших, а ради этого мне думается не стоит индексировать данные.
Алексей1153
ViGOur, я оговорился - не индексированные, а отсортированные ))
ViGOur
В таком случае будет потрачено кучу времени на сортировку! Лучше тогда уж индексация, времени затратится меньше! :)

Так что не отходим от условия! :)
Iron Bug
дык, тебе уже написали: пройтись линейно по всему списку и сделать выборку. это самое быстрое решение в один проход.

а ограничение ничего на даёт, если числа рациональные. там между любыми точками может быть бесконечно много значений.
ViGOur
Iron Bug, я знаю ответ. Просто точный ответ, дал только Алексей1153, после чего скрыл спойлером! :D
От других точного ответа как и от тебя не было! :)

Так как линейность и называлась, то получается, что алгоритм отработает за O(n + x), но вот х пока не назвали каким будет!
wiz29
список из N сортированных элементов поддерживать элементарно просто не расходуя на это кучу ресурсов, тк изначально он будет состоять из 1го элемента, затем из 2х и тд, добавлять в сортированный список 1 элемент по моему не проблематично

Цитата(ViGOur @ 23.1.2012, 18:07) *
А что оно тебе даст? Я понимаю, что в случае 0 <= X <= 2 по сравнению с 0 <= X <= 1000 увеличится скорость алгоритма. Но нас то интересует, алгоритм, который будет универсален как для одного, так и для другого случая и так же быстр! :)


Видимо просто не понятен был смысл вопроса, когда о природе чисел известно больше, то возможна какая то оптимизация, изменение одного инфинитивного интервала на другой ровным счетом не добавляет никаких новых знаний о природе чисел из множества X.
ViGOur
Это не реальная задача, а чисто алгоритмическая, чтобы мозг расслабить! ;)
wiz29
алгоритм однопроходный с поддержанием в отсортированном состоянии списка из N наименьших значений.
cross
Поправьте если я не прав, но разве поддержание отсортированного списка не сложности logN? Тем самым общая сложность задачи: M*logN? А при не большом Х и достаточной памяти, можно добиться линейности при индексировании элементов.
igor_bogomolov
ViGOur, так была уже такая тема. Ты же и создавал
http://www.forum.crossplatform.ru/index.php?showtopic=5460
ViGOur
Ну наконец-то! И решение и вспомнили! :D
AD
Цитата(ViGOur @ 24.1.2012, 14:32) *
Ну наконец-то! И решение и вспомнили! :D

Перечитал ту тему.

А твое решение без использования STL так и не увидели.

Хотя решение в последних двух постах очень понравилось!

Все украдено до нас! :)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2019 IPS, Inc.