Pull to refresh
10
0
Eugene Savin @esavin

IT

Send message
Не разделяю я любовь отечественных программистов к функции XOR.

Берём P1=257, P2=16777259, рассматриваем две точки на плоскости.
В промежутке от 0 до 1500 — нет коллизий. В промежутке от 0 до 3000 получаем уже 3504 коллизии. Заменяем XOR на обычное сложение — коллизий не будет и в более широком промежутке.
Своей статьёй я хотел поднять вопрос, который особо нигде не обсуждается.

Я встречал обсуждения про overhead на переключение между tread'ами, а про эффективность реализации hash функции — нет.

Универсальная реализация может быть хорошая, а может быть и не очень. Для примера из 3 short полей (как у Блоха) эта реализация не очень удачная. Если человеку нужно реализовать hashCode(), то он, обычно, или сгенерирует его с средствами IDE или обратиться к Блоху или Эккелю. И получит не очень хороший результат.

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

Кстати, для диапазона от 230 до 230+100 результат будет тот же.
Еще я забыл написать в статье, что алгоритм от Блоха оставляет незадействованным промежуток от 0 до 17*372 (для двух переменных). Для 3-х переменных степень при 37 будет равна трем. А это 861101. Понятно, что после переполнения этот промежуток тоже будет использован, но как-то не очень красиво.

Собственно, подобную ошибку допустил и я в своем примере. Правильная hash функция будет иметь вид:
p*x1+q*y1-min(p,q)=h
Руслан, я проверял этот диапазон. Результат тот же. Если в формуле (x1 — x2) / (y2-y1) = q умножить числитель и знаменатель на любое целое число, то коллизия останется, но ее можно будет сдвинуть по числовой оси.

Прошу прощения, промахнулся с ответом.
В этом случае Вам будет тяжело по hash коду различить даже (1, 0) и (0, 1).
2

Information

Rating
Does not participate
Registered
Activity