venco писал(а):
e2e4, я подозреваю, что вы так пошутили, но, боюсь, Lotos шутки не оценит.
Да нет, вроде не шутил. Я попытался показать некоторый "инженерный" подход к делу - может быть, конкретно здесь и не очень удачный, т.к. алгоритмы сортировки уже написаны дядей Васей (и даже с большой долей верятности не содержат ошибок
).
Если задача не учебная, а реальная - всегда ее нужно оценивать с разных сторон, и быстрота написания кода/простота (а, следоватлеьно, надежность) отладки - выливаются в конце концов в экономику. Когда я вижу такую постановку задачи, как в первом сообщении - есть какие-то определенные цифры, четко очерчены рамки - всегдя тянет прикинуть несколько вариантов, и, если самый простой возможен - принимается как правило, именно он.
-- Пт окт 09, 2009 02:39:04 --Maslov писал(а):
Какое-то немного неэстетичное решение Вы предлагаете
Полностью с Вами согласен
. Я не предлагаю, я только предлагаю его обсудить, а потом - отклонить
.
Maslov писал(а):
А вообще было бы интересно сравнить по времени работы и затратам на программирование/отладку все три способа - без сортировки, с сортировкой только второго, и с сортировкой хэшей и последующим их сравнением за один параллельный проход по двум массивам.
Еще один способ - хэши посчитать, но их не сортирвать. В качестве хэша можно взять простую контрольную сумму по модулю
, к примеру. Уже будет существенное ускорение без необходимости писать сортировку, что сложнее.
Maslov писал(а):
2 массива по 50000 строк по 260 символов с общим префиксом 256 байт сравниваются "в лоб" все-со-всеми около 20 сек (на одном процессоре Core2Duo 2.4 GHz). При этом все работает под .Net, так что все строки юникодные (2 байта на символ). C++ будет работать быстрее.
Хммм... я ошибся в
= 535 раз? Странно. Вряд ли дело в оптимизации на уровне процессора. Где же ошибка? Завтра сам напишу подобную программу и потестирую на рабочем Pentium M @1,86 GHz.