Всего миллион записей и для их обработки нужны часы??? Я думаю их можно загрузить все в память секунды за две, любую операцию сделать максимум за одну и записать все взад с индексом ну за 10. Почему часы???

"I always like to say: if we had surveyed ... probably would have had a 95% refusal rate" это не совсем "если бы эти инъекции были представлены на рынке в том виде, в каком они есть на самом деле, то Bayer получил бы 95% отказов от этих уколов "

Я имел в виду open/linked. Большее количество хэшей это больше про детали имплементации (несоменно, очень интересные, но тут было про простейшие коллекции)

Там нет "теории". Я в предыдущем комментарии описал как это работает, любой программист который может писать код сможет по этому описанию написать имплементацию. Точно так же как и FuzzBuzz не имеет теории, просто немного несложного кода.

Правда в то же время я вижу что некоторые программисты не умеют писать код от слова вообще, но этот феномен я совсем не понимаю.

Ничего личного. Я полностью уверен что если вы пишите программы, то вы правда сможете написать хэшмапку, особенно если дома, для себя и без стресса. Вы же знаете, то там массив, хэш, остаток от деления и коллизии разрешаются обычно связанным списком. Вот скажите, что, правда не сможете? Если нет, то как на работе код пишете?

Я не спрашиваю. Но у нормального разработчика не составит труда показать, как он умеет писать код для реализации простой задачи. Если кто-то считает эту задачу очень сложной, то я не знаю, можно в таксисты пойти.

Зависит от платформы, я думаю. В яве можно command-left click и посмотреть имплементацию, по умолчанию это адрес объекта вроде, для строк это простой хэш от содержимого. В Go это aeshash от содержимого.

B-tree это упрощенное 2-3 дерево, в нем нет хэшей. Так что да, BST и hash maps это две сильно разных структуры.

Обычно имплементация hashcode контролируется, но данные могут и нет. Если данные - это, например, строки, которые приходят от пользователей, то это можно использовать для DOS атаки.

Да, все верно. И для хэшмапки самый плохой случай для этого кода будет O(n^2), что будет отличным сюрпризом если там несколько миллионов элементов. Не зная как это устроено будет сложно сказать какого черта все встало ) Так же будет сложнее сказать RB или AVL дерево для вот именно для этого плохого перебора будет лучше.

Знание сложности не всегда достаточно даже для тривиальных оценок. Скажем, какой big-O у "for(key : map.keys()) print(map[key])" и почему?

А знание как оно внутри у разных коллекций устроено использую каждый день на работе.

Ну не на работе, но недавно писал k-nearest neighbor на хэш-таблицах для многомерных векторов, а что? Хотите сказать, что знание что в хэш таблицах используется оператор MOD это слишком сложно и совершенно бесполезно?

Ну да, этого достаточно чтоб написать свою хэшмапку, не правда ли?

Нужно это чтоб понимать как оно работает и, например, не написать случайно перебор содержимого с квадратичной сложностью или там не класть в нее объекты у которых hashCode/equals контракт нарушен. Или же тут ситация сложнее и есть непонимание чем хэштаблица от массива отличается?

Можно поподробнее пожалуйста? Как из 29.01B долларов оборота за квартал получилось 1 990 984 950 рублей и 5 копеек, я правда не понимаю.

Да. Все используют хэш таблицы чуть ли не каждый день, и надо знать и самому уметь ее написать. Там, массив, остаток от деления и два вида разрешения коллизий, причем можно знать любой один. Это что, невозможное знание?

Глубоко вдохните и примите тот факт что есть разные диалекты разных языков. Очень странно переживать от того что кто-то говорит не так или не на том же языке или диалекте, что и вы.