Если выяснится, что MD5 недостаточно безопасен, будут проблемы.
неверно (если я правильно понял алгоритм, конечно).
В данном случае хэш-функция используется только для того, чтобы сделать ключ шифрования более «псевдослучайным» — при этом злоумышленник даже в случае компрометации MD5 ничего сделать не может, ибо не видит результат хэширования. В случае применения вместо AES идеальной PRP хэширование можно вообще не применять с тем же результатом.
Авторотация на маленьких моделях нормально не работает. Фактически (если говорить в терминах модельных классов) — от 600го и выше, а это уже очень недешевый класс.
Бензиновые вертолеты — это более частое техобслуживание (из-за увеличенной вибрационной нагрузки), проблемы с заправкой (электроквадрокоптер может прилететь, зарядиться, взять груз и улететь без участия человека), более сложное управление.
В конце концов, вертолет — это банально повышенная опасность. Если от квадрика опасность разве что из-за падения сверху (и то — мб можно и с парашютами что-нибудь сообразить), то у вертолета есть такая штука, как движущиеся с >100м/с законцовки лопастей, которые рубят в фарш не то что людей, но даже автомобили.
Вверху есть выдержка из договора. Оттуда:
"...you may not… use the Service to facilitate public Internet access (such as through a Wi-Fi hotspot), use it for high volume purposes… or use the Service to host any type of server."
Если переводить с юридического на человеческий — «нате вам быстрый интернет, с которым не нужно волноваться о потребленном трафике, но будьте добры не злоупотреблять.»
Делов-то — загружаем в принтер плутониевую проволоку, тюним экструдер, чтобы грелся до 639,7 °C, печатаем шарик… Остается только напечатать нейтронный инициатор и обжимные заряды с детонаторами — и бомба готова!
Дома (Украина) держали температуру в помещении в 20-21. Сейчас (Голландия) температура в доме (да и в офисе) держится в 18,5 — ну принято тут так. Дискомфорта ни я, ни жена не испытываем.
Как можно постоянно находиться при +25 — плохо себе представляю.
При пролистывании страницы закоговок как бы уезжает вверх вместе с документом. Работает только на телефонах. Очень удобно, кстати — заметно повышается полезная площадь.
Подобное поведение раньше я, если не путаю, в Сафари видел.
Избыточная память относительна. Если принять load factor за 0.5 (что явно избыточно) — в хэш-таблице будет N пустых записей. При этом пустая запись — это всего лишь десяток байт на пустой указатель, поэтому откуда тут «в несколько раз больше» — в упор не вижу. На 20%-30% больше разве что.
Сложность вычисления хэшкодов компенсируется относительной (по сравнению со строковым сравнением в случае сортировки) простотой сравнения.
Если принять средний размер записи во входящих данных за, допустим, 50 байт (стринг*2, ибо юникод, +оверхед на собственно объекты), то на 100ГБ данных получим 2*10^9 записей. Это ИМХО несколько многовато как для внешней строковой сортировки на обычной машине.
В данном случае все (почти) однозначно.
Если мы решаем абстрактную алгоритмическую задачу — достаточно сказать, что решение на хэш-таблицах имеет меньшую асимптотику.
Если мы решаем практическую задачу — решение с хэш-таблицами работает быстро и за один проход, в то время как решение с сортировкой обладает следующими недостатками:
— оно сильно медленнее (ниже подробности)
— имеет такую же асимптотику по памяти (для хранения результата)
— входящие коллекции должны поддерживать произвольный доступ (прощайте, курсоры базы данных и прочее подобное);
— входящие коллекции должны быть мутабельными (или сортировка в новые коллекции, что не ускоряет).
— решение требует больше строк кода.
Сортировка будет значительно медленнее как минимум потому, что она использует строковые сравнения, в то время как хэш-таблицы — сравнение хэшей. Надо ли объяснять, почему константа для сортировки увеличивается в М (средняя длина строки) раз?
Касательно коллизий — это легко проверить.
Вот прямо сейчас я взял первую книгу «Войны и Мира», разбил ее на слова (229540 слов, к слову) и составил (неповторяющиеся) строки из последовательно идущих 2,3,...,10 слов. Получилось 416588 фраз, причем не абстрактных, а вполне себе применимых в жизни.
На этом наборе коллизий у нас получилось целых 23.
Примеры коллизий:
«он. – Денисов, ты»
«пожилая дама. Князь»
«генералу. Здесь»
«лесом берег»
«что его»
«что же?»
И т.д.
Вы действительно считаете, что ~50 коллизий на миллион что-то решают?
То и значит.
Опишите мне, пожалуйста, алгоритм мержсорта, который позволил бы сортировать не полностью лежащий в памяти массив.
> Идеальная хеш-функция это как идеальный архиватор, вроде бы можно, но не существует в жизни.
Это демагогия. Давайте конкретно: сколько коллизий вы встретите в жававской реализации строковых хэшкодов на, скажем, 1кк реальных строк из условия?
Да, и что такое — «идеальный архиватор», который «вроде бы можно»?
> По крайней мере в той же Java есть и SortedMap и TreeMap
Этого, извините, не понял. Раз уж мы обсуждаем именно Java — вы, конечно, в курсе, что SortedMap — это интерфейс, а TreeMap — его реализация на основе двоичных деревьев (с асимптотикой O(NlogN))?
Коллизии в String.hashcode() — вещь настолько редкая, что в реальной жизнии ее можно не учитывать.
Ну и решение есть выше — покажите мне — откуда там возьмется большая константа?
rebase — инструмент не для начинающих, тут я согласен. Однако, он опупительно полезен и в повседневной работе при должном умении, ибо позволяет сделать историю гораздо читабельнее (особенно в свете отсутствия веток в гите). Впрочем, не буду повторяться, ибо понятно, что мнений на этот счет может быть несколько.
Не зависит.
Решение линейно по памяти, значит если в память влазят исходные данные — влезет и мапа. Если не влазят — решение с сортировкой тоже не пойдет.
Хеш-функция для стрингов хорошая во всех известных мне языках. Не бывает случаев.
100к записей влезут аж со свистом. И 100м влезут — хватило бы памяти.
public Collection<Record> merge(Collection<Record> a, Collection<Record> b) {
Map<String, Record> map = new HashMap<String, Record>();
for (Record r : b)
map.put(r.word, r);
for (Record r : a)
map.put(r.word, r);
return map.values();
}
Вы же понимаете, к чему это, правда?
Однако вот это:
неверно (если я правильно понял алгоритм, конечно).
В данном случае хэш-функция используется только для того, чтобы сделать ключ шифрования более «псевдослучайным» — при этом злоумышленник даже в случае компрометации MD5 ничего сделать не может, ибо не видит результат хэширования. В случае применения вместо AES идеальной PRP хэширование можно вообще не применять с тем же результатом.
Впрочем, квадрик тоже эти 2 кило не донесет. Думается мне, что под мелкими пакетами имеется в виду что-то веса писем и прочих бумажек.
Бензиновые вертолеты — это более частое техобслуживание (из-за увеличенной вибрационной нагрузки), проблемы с заправкой (электроквадрокоптер может прилететь, зарядиться, взять груз и улететь без участия человека), более сложное управление.
В конце концов, вертолет — это банально повышенная опасность. Если от квадрика опасность разве что из-за падения сверху (и то — мб можно и с парашютами что-нибудь сообразить), то у вертолета есть такая штука, как движущиеся с >100м/с законцовки лопастей, которые рубят в фарш не то что людей, но даже автомобили.
"...you may not… use the Service to facilitate public Internet access (such as through a Wi-Fi hotspot), use it for high volume purposes… or use the Service to host any type of server."
Если переводить с юридического на человеческий — «нате вам быстрый интернет, с которым не нужно волноваться о потребленном трафике, но будьте добры не злоупотреблять.»
Как можно постоянно находиться при +25 — плохо себе представляю.
Подобное поведение раньше я, если не путаю, в Сафари видел.
Сложность вычисления хэшкодов компенсируется относительной (по сравнению со строковым сравнением в случае сортировки) простотой сравнения.
Если принять средний размер записи во входящих данных за, допустим, 50 байт (стринг*2, ибо юникод, +оверхед на собственно объекты), то на 100ГБ данных получим 2*10^9 записей. Это ИМХО несколько многовато как для внешней строковой сортировки на обычной машине.
Если мы решаем абстрактную алгоритмическую задачу — достаточно сказать, что решение на хэш-таблицах имеет меньшую асимптотику.
Если мы решаем практическую задачу — решение с хэш-таблицами работает быстро и за один проход, в то время как решение с сортировкой обладает следующими недостатками:
— оно сильно медленнее (ниже подробности)
— имеет такую же асимптотику по памяти (для хранения результата)
— входящие коллекции должны поддерживать произвольный доступ (прощайте, курсоры базы данных и прочее подобное);
— входящие коллекции должны быть мутабельными (или сортировка в новые коллекции, что не ускоряет).
— решение требует больше строк кода.
Сортировка будет значительно медленнее как минимум потому, что она использует строковые сравнения, в то время как хэш-таблицы — сравнение хэшей. Надо ли объяснять, почему константа для сортировки увеличивается в М (средняя длина строки) раз?
Касательно коллизий — это легко проверить.
Вот прямо сейчас я взял первую книгу «Войны и Мира», разбил ее на слова (229540 слов, к слову) и составил (неповторяющиеся) строки из последовательно идущих 2,3,...,10 слов. Получилось 416588 фраз, причем не абстрактных, а вполне себе применимых в жизни.
На этом наборе коллизий у нас получилось целых 23.
Примеры коллизий:
«он. – Денисов, ты»
«пожилая дама. Князь»
«генералу. Здесь»
«лесом берег»
«что его»
«что же?»
И т.д.
Вы действительно считаете, что ~50 коллизий на миллион что-то решают?
Опишите мне, пожалуйста, алгоритм мержсорта, который позволил бы сортировать не полностью лежащий в памяти массив.
> Идеальная хеш-функция это как идеальный архиватор, вроде бы можно, но не существует в жизни.
Это демагогия. Давайте конкретно: сколько коллизий вы встретите в жававской реализации строковых хэшкодов на, скажем, 1кк реальных строк из условия?
Да, и что такое — «идеальный архиватор», который «вроде бы можно»?
> По крайней мере в той же Java есть и SortedMap и TreeMap
Этого, извините, не понял. Раз уж мы обсуждаем именно Java — вы, конечно, в курсе, что SortedMap — это интерфейс, а TreeMap — его реализация на основе двоичных деревьев (с асимптотикой O(NlogN))?
Ну и решение есть выше — покажите мне — откуда там возьмется большая константа?
Решение линейно по памяти, значит если в память влазят исходные данные — влезет и мапа. Если не влазят — решение с сортировкой тоже не пойдет.
Хеш-функция для стрингов хорошая во всех известных мне языках. Не бывает случаев.
100к записей влезут аж со свистом. И 100м влезут — хватило бы памяти.