День добрый.
Столкнулся с такой проблемой, нужно отсортировать 100000 (сто тысяч) элементов. В массив не лезет. Организовал работу с файлом (с 2-я, если быть точным) - работает очень медленно. Подумал на постоянные read/write, оптимизировал, считывает из файла сразу большое кол-во элементов в массив, сортирует, сливает в файл. Быстрее почти не стало. Я так понимаю такой варинт оптимизировать для работы со 100000 эл-ми не удастя...
В памяти сортировать тоже не получается, грешит на нехватку места. Поискал, увидел, что паскаль дает не больше 640 кб на всю программу.
Подскажите, какие есть варианты сортировки такой большой штуковины?
Спасибо.
100000 элементов какого типа?
внешние сортировки....
поищи по форуму (вроде было) сортировку слиянием, например.
Прошу прощения, в голове туча мыслей, поэтому пост такой сумбурный. Пока что применял метод пузырька, потому что в работе с отдельными "блоками" другими известными мне алгоритмами (правда не так много я их знаю) будет пользоваться, как мне кажется, неудобно.
Элемент - вещественная переменная.
Попробовал загонять в нетипизированный файл сразу по 10000 эл-тов за раз... в ходе написания кода, понял что могу ограничить элементы типом single (4 байта) и уложиться в отведенные 500+ Кб.
Всем спасибо, кажется проблем возникнуть больше не должно. По крайней мере с общим объемом.
Ну я сейчас реализовываю массив из 10 нетипизированных указателей по 40 Кб. Как раз на 100000 синглов хватит.
Во-первых, кто сказал, что будет использоваться именно метод пузырька? hardcase, тебе что, автор об этом сообщил? Или это чья-то творческая придумка? Так вот не надо ничего придумывать...
Кстати, ничего более НЕкорректного, чем посоветовать для сортировки 100000 (СТА ТЫСЯЧ!!!) элементов РЕКУРСИВНУЮ быструю сортировку я не видел... Тем более НЕ в разделе 32-битных компиляторов (хотя и там тоже ресурсы не безграничны)
(Только не надо ничего говорить об избавлении от рекурсии в QuickSort... Это потребует ЕЩЕ дополнительной памяти, которая и так на пределе...)