Сортировка в Python 3

[helg]

В случае key() у алгоритма сортировки сильно больше возможностей для оптимизации процесса, чем в случае cmp().

Доб. В рассматриваемом случае я бы сделал примерно так (чтобы не задумываться: с нуля нам отсчёт или с единицы)
key = (13*(year-1900) + month)*32 + day
целые числа и готовятся и сравниваются быстрее, чем строки.

А почему просто не возвращать конвертированное в int строчное значение даты в формате YYYYMMDD?

Можно и так. Но это потребует преобразования трёх числел в ASCII строки, склеивания и парсирования полученной строки в число. Не очень накладно, но всё же операции string<->int - это, как минимум, циклы. С позиции дотошного оптимизатора это всё-таки затратнее для железки, чем простая арифметика.

[timeau]

Да в этом питоне сортируются не только овеществлённые коллекции, но и вполне себе виртуальные, сгенерированные. Метрики генераторов, особенно тривиальных, коих так много в питонокоде, известны безо всяких проходов по элементам. Да и лямбды для key() обычно тоже немудрёные, так что оптимизатор может их понять. А раз всё известно заранее, можно выбрать правильный алгоритм сортировки. Более того, оптимизатор может даже решить, что не надо громоздить паровоз из генератора и сортировщика, а достаточно просто воткнуть какой параметр в существующий генератор.

А вот тут давайте поподробнее. Поскольку:
1. Лямбды в Питоне нетривиальными не бывают. Они все вида "x:return действие над х", потому вопрос с оптимизатором подвисает в воздухе.
2. Я больше чем уверен, что алгоритм сортировки один на все случаи жизни.
3. Генераторы, AFAIK, в сортировках недопустимы в принципе, по крайней мере в виде key=XXX функции.

Вы не верите, что получая за вопрос 64 бита информации можно найти ответ быстрее, чем получая только полтора бита за вопрос?

Я не не верю, я не понимаю, к чему это тут вообще. Это вообще к делу не относится, ИМО. Мы говорили о "троичном" флаге, Вы сказали о полутора битах. При чем тут возвращаемое 64-битовое число? С какого оно тут бока?

А почему просто не возвращать конвертированное в int строчное значение даты в формате YYYYMMDD?

Можно и так. Но это потребует преобразования трёх числел в ASCII строки, склеивания и парсирования полученной строки в число. Не очень накладно, но всё же операции string<->int - это, как минимум, циклы. С позиции дотошного оптимизатора это всё-таки затратнее для железки, чем простая арифметика.

Нет, категорически. Переменная в нетипизированном языке типа Перла или Питона совсем не просто 64 int, это объекты (хэши), что подтверждается значениями типа None or undef. У Python так и вовсе парадигма "все есть объект". Отсюда и совершенно идиотские конструкции объединения массива

Code: Select all

','.join(list)

где в качестве объекта выступает объект константного разделителя, в данном случае запятой. Потому склеивание совсем не такое, как можно было бы ожидать из C/C++, etc.

[ALV00]

В случае key() у алгоритма сортировки сильно больше возможностей для оптимизации процесса, чем в случае cmp().

Доб. В рассматриваемом случае я бы сделал примерно так (чтобы не задумываться: с нуля нам отсчёт или с единицы)
key = (13*(year-1900) + month)*32 + day
целые числа и готовятся и сравниваются быстрее, чем строки.

А почему просто не возвращать конвертированное в int строчное значение даты в формате YYYYMMDD?

Можно и так. Но это потребует преобразования трёх числел в ASCII строки, склеивания и парсирования полученной строки в число. Не очень накладно, но всё же операции string<->int - это, как минимум, циклы. С позиции дотошного оптимизатора это всё-таки затратнее для железки, чем простая арифметика.

year*10000 + month*100 + day

[M. Ridcully]

В случае key() у алгоритма сортировки сильно больше возможностей для оптимизации процесса, чем в случае cmp().

Доб. В рассматриваемом случае я бы сделал примерно так (чтобы не задумываться: с нуля нам отсчёт или с единицы)
key = (13*(year-1900) + month)*32 + day
целые числа и готовятся и сравниваются быстрее, чем строки.

А почему просто не возвращать конвертированное в int строчное значение даты в формате YYYYMMDD?

Можно и так. Но это потребует преобразования трёх числел в ASCII строки, склеивания и парсирования полученной строки в число. Не очень накладно, но всё же операции string<->int - это, как минимум, циклы. С позиции дотошного оптимизатора это всё-таки затратнее для железки, чем простая арифметика.

year*10000 + month*100 + day

Ещё раз - а чего мешает tuple вернуть - year, month, day?

[ALV00]

Ещё раз - а чего мешает tuple вернуть - year, month, day?

Я думаю, по большому счету пофиг. Лишние несколько операций с памятью рояля не сыграют.

[M. Ridcully]

Ещё раз - а чего мешает tuple вернуть - year, month, day?

Я думаю, по большому счету пофиг. Лишние несколько операций с памятью рояля не сыграют.

Ну, с таким буддистским подходом, да. Безусловно. У настоящего программиста программа на любом языке должна выглядеть, как программа на Фортране Брейнфаке

А в соседней теме, вон, пишут, что "индусский говнокод" кому-то не нравится.