Резюме. Мы обсуждаем здесь наилучшие способы оптимизации сортировки сверх-больших массивов составных объектов по нечисловым ключам. Также рассматривается способ уменьшения количества выполняемых операций (сложность) имеющихся алгоритмов сортировки. Конкретный базовый алгоритм сортировки выбирается разработчиком по своему усмотрению (см. условие 1 в замечаниях).

Введение: Проблематикой имплементации паралелльной сортировки занимаются разные специалисты по всему миру. Подавляющее число специалистов рассматривает платформы GPU и их суперскалярность как эффективную (в вычислительном плане) базу для разработки новых алгоритмов. На Хабре исследованиями в этой области занимались [KS1], [KILY1], [PatZ1], [Ms1].

Стоит отметить несколько минусов выбранного авторами похода:

Приветствую, друзья! В прошлой статье я предлагал на обсуждение какой-то бред, за который теперь стыдно черновик нового протокола аутентификации на сайтах. И хотя сейчас я значительно его переработал (с учетом ваших замечаний) и готовлю новую версию, я решил что стоит предварительно опубликовать несколько статей, которые будут раскрывать мотивы технических решений, закладываемых в новый протокол. А эта статья посвящается проблемам и техникам безопасной передачи и хранения сайтами ваших паролей.

Я приведу несколько реально используемых схем, встречаемых на практике. Буду приводить схемы авторизации в порядке от простого к сложному, показывая их преимущества и недостатки и обосновывая выбранные технические решения.

Теперь кратко о себе: Я опасно некомпетентен в криптографии. Это всё, что вы должны обо мне знать.

Давным-давно наш коллега @novar разместил на Хабре статью с описанием вот такого незатейливого ТЗ, полученного им от потенциального работодателя:

Реализовать класс для задания и расчета времени по расписанию. Расписание задано в стиле crontab (точный формат см. во вложении), требуется находить ближайшие в будущем или прошлом моменты, попадающие в это расписание. Обращаю Ваше внимание, что класс должен быть эффективным и не использовать много памяти и ресурсов даже тогда, когда в расписании задано много значений. Например очень много значений с шагом в одну миллисекунду.

Хочу предложить алгоритм, приближающийся к O(1) во всех возможных ситуациях, вместо оригинального O(n). Интересующихся прошу под кат.

Ах да. Если вы тот самый работодатель, вот готовый код под ваше ТЗ. Правда на Java, а не на C#. Но вы же не думали, что всё будет так просто?