Сообщение Re[11]: std::hash от 11.10.2017 13:32
Изменено 11.10.2017 13:33 Qbit86
Re[11]: std::hash
Здравствуйте, MTD, Вы писали:
MTD>Это смотря, что за задача, возможно мне хеш нужен не для таблицы.
Ну так берёшь его и считаешь по-своему, в чём проблема? И не используешь не по назначению функцию, которая «designed to work with unordered associative containers... The unordered associative containers... use specializations of the template std::hash as the default hash function.» ©
Q>>Если индекс рассчитывается как k mod M, то коллизии будут при arity(k) > arity(M).
MTD>А если у тебя количество бакетов — степень двойки и номер бакета hash(k) & M коллизий не будет что-ли?
Будут при arity(k) > arity(M). Это пример был к тому, что твоя identity — никак не «идеальная».
MTD>Допустим, мне просто нужен хеш, при хеш = k коллизий гарантировано нет.
Так и используешь k, не вызывая никаких std::hash.
MTD>Не убедительно. Почему в одном случае надо специально подбирать, а во втором само получится?
Вот скажем ты отфильтровал из базы всех пользователей-женщин, и используешь их идентификаторы как ключи. А админ базы в своё время решил при создании всем пользователям женщинам-назначать id кратный 7, мол, их всё равно в шесть раз меньше в компании; почему нет. У тебя образовалась неявная связь, не случайная. А если у тебя рандомизация, без явной закономерности, то в такие совпадения почти невозможно попасть. Нет правдоподобных сценариев.
MTD>То есть в Майкрософте сделали фигню? Ну ок.
Почему фигню, если вычислять индекс делением на степень двойки быстрее, чем делением на простое число?
MTD>Это смотря, что за задача, возможно мне хеш нужен не для таблицы.
Ну так берёшь его и считаешь по-своему, в чём проблема? И не используешь не по назначению функцию, которая «designed to work with unordered associative containers... The unordered associative containers... use specializations of the template std::hash as the default hash function.» ©
Q>>Если индекс рассчитывается как k mod M, то коллизии будут при arity(k) > arity(M).
MTD>А если у тебя количество бакетов — степень двойки и номер бакета hash(k) & M коллизий не будет что-ли?
Будут при arity(k) > arity(M). Это пример был к тому, что твоя identity — никак не «идеальная».
MTD>Допустим, мне просто нужен хеш, при хеш = k коллизий гарантировано нет.
Так и используешь k, не вызывая никаких std::hash.
MTD>Не убедительно. Почему в одном случае надо специально подбирать, а во втором само получится?
Вот скажем ты отфильтровал из базы всех пользователей-женщин, и используешь их идентификаторы как ключи. А админ базы в своё время решил при создании всем пользователям женщинам-назначать id кратный 7, мол, их всё равно в шесть раз меньше в компании; почему нет. У тебя образовалась неявная связь, не случайная. А если у тебя рандомизация, без явной закономерности, то в такие совпадения почти невозможно попасть. Нет правдоподобных сценариев.
MTD>То есть в Майкрософте сделали фигню? Ну ок.
Почему фигню, если вычислять индекс делением на степень двойки быстрее, чем делением на простое число?
Re[11]: std::hash
Здравствуйте, MTD, Вы писали:
MTD>Это смотря, что за задача, возможно мне хеш нужен не для таблицы.
Ну так берёшь его и считаешь по-своему, в чём проблема? И не используешь не по назначению функцию, которая «designed to work with unordered associative containers... The unordered associative containers... use specializations of the template std::hash as the default hash function.» ©
Q>>Если индекс рассчитывается как k mod M, то коллизии будут при arity(k) > arity(M).
MTD>А если у тебя количество бакетов — степень двойки и номер бакета hash(k) & M коллизий не будет что-ли?
Будут при arity(k) > arity(M). Это пример был к тому, что твоя identity — никак не «идеальная».
MTD>Допустим, мне просто нужен хеш, при хеш = k коллизий гарантировано нет.
Так и используешь k, не вызывая никаких std::hash.
MTD>Не убедительно. Почему в одном случае надо специально подбирать, а во втором само получится?
Вот скажем ты отфильтровал из базы всех пользователей-женщин, и используешь их идентификаторы как ключи. А админ базы в своё время решил при создании всем пользователям-женщинам назначать id кратный 7, мол, их всё равно в шесть раз меньше в компании; почему нет. У тебя образовалась неявная связь, не случайная. А если у тебя рандомизация, без явной закономерности, то в такие совпадения почти невозможно попасть. Нет правдоподобных сценариев.
MTD>То есть в Майкрософте сделали фигню? Ну ок.
Почему фигню, если вычислять индекс делением на степень двойки быстрее, чем делением на простое число?
MTD>Это смотря, что за задача, возможно мне хеш нужен не для таблицы.
Ну так берёшь его и считаешь по-своему, в чём проблема? И не используешь не по назначению функцию, которая «designed to work with unordered associative containers... The unordered associative containers... use specializations of the template std::hash as the default hash function.» ©
Q>>Если индекс рассчитывается как k mod M, то коллизии будут при arity(k) > arity(M).
MTD>А если у тебя количество бакетов — степень двойки и номер бакета hash(k) & M коллизий не будет что-ли?
Будут при arity(k) > arity(M). Это пример был к тому, что твоя identity — никак не «идеальная».
MTD>Допустим, мне просто нужен хеш, при хеш = k коллизий гарантировано нет.
Так и используешь k, не вызывая никаких std::hash.
MTD>Не убедительно. Почему в одном случае надо специально подбирать, а во втором само получится?
Вот скажем ты отфильтровал из базы всех пользователей-женщин, и используешь их идентификаторы как ключи. А админ базы в своё время решил при создании всем пользователям-женщинам назначать id кратный 7, мол, их всё равно в шесть раз меньше в компании; почему нет. У тебя образовалась неявная связь, не случайная. А если у тебя рандомизация, без явной закономерности, то в такие совпадения почти невозможно попасть. Нет правдоподобных сценариев.
MTD>То есть в Майкрософте сделали фигню? Ну ок.
Почему фигню, если вычислять индекс делением на степень двойки быстрее, чем делением на простое число?