Имя (желательно полное):

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).
> Вадим, спасибо за ответ! > >для однородных данных - чем больше, тем лучше. > На практике, однако, этот размер ограничивают > с целью ограничения расходов памяти. > Ясно, спасибо. Соображения удобства, вот значит как... > Хорошо. Я-то боялся, что ограничения вызваны > неприличными тормозами. > >> с весьма небольшими затратами времени, грубо оценивая > -- линейными от размера блока. > >Это смотря, с какими небольшими. В любом случае, > >хороший результат. Если есть желание, могу замерить > >на данных из VYCCT. > ну само время я измерять не хотел бы :) оптимизацию не делал, > только-только реализовал сам алгоритм. > но я считаю количество обращений к данным. Желаете сравнить? > вот, к примеру. ("Белые Одежды", Виктор Дудинцев) L=1.3 Мб : > коэффициент при L равен 42. > 420 Кб (Ray Bradbury, Dandelion Wine): ко=43. > 6 мегабайт логов tcpdump: ко=67. > 1musk10.txt, 1.3 Мб: ко=51. > >И не могу понять: новый это результат, > >либо всем давно известный и неинтересный. > теперь понимаю: не новый... да, в общем-то, > никакие супер-пупер фокусы у меня не применяются ;-) > >Кхе-кхе. Кто ж заставляет явно хранить всю матрицу > >перестановок? Достаточно массива указателей на начала строк. > я знаю! :) > >Советую критически воспринимать высказывание > >об таком ограничении размера блока. Тем более, > >что существование архиваторов, достаточно шустро > >выполняющих сортировку мегабайтовых блоков далеко > >не редкость. > Теперь-то ясно. А ведь ещё позавчера такое существование > было для меня совсем неочевидно... > с таким разнообразием сведений :) > Я ещё вернусь... :)

Пожалуйста, заполните все поля.
И не нажимайте по два раза на кнопку! Дождитесь ответа сервера.