от str(df.uids)
фреймы на разных контейнерах, гонять данные между ними затруднительно
некорректно
странное поведение, а если серию предварительно обернуть в список то ничего не теряется
наверное не столь странное сколь неочевидное
А вот у меня тоже вопрос про это: можно ли хеш дф делать так: functools.reduce(lambda acc, el: acc+hash(el), df['id'], 0)
А почему?
потому что хеши нельзя складывать
выглядит как некая малоэффективная вариация на тему тигрохэша. Как минимум будет лучше объединять хеши по парам, тогда сложность будет логарифмическая.
Загуглил tiger hash, абсолютно нихрена не понял
А кто запретил? И какое именно полезное свойство хешей потеряется при этом?
потому что сумма хешей кусков данных и хеш сразу всех кусков данных это не одно и то же, или по крайней мере странно было бы это предполагать, не зная свойств конкретной хеш-функции и не являясь специалистом про криптографии
А зачем это предполагать?
потому что хеш-функции заточены под то, чтобы иметь минимальную вероятность коллизии, когда вы начинаете хеши складывать, это свойство может потеряться
А может не потеряться. Особенно если способ разбивания на куски одинаков. И тут даже не криптография, а кеширование.
во-первых, хеширование, во-вторых, хеширование это криптография если вы хотите использовать хеш-функцию как ключ для кэша, лучше всего ей пользоваться нормально, чтобы не возникло коллизии и вы не отдали пользователю чужие данные из кэша, например
ну типа это рассуждение про может или не может потеряться я готов послушать от практикующего специалиста хеш-алгоритмам
Кеширование. Кеширование результата вычисления сравнения df
Ну в принципе страшно получить коллизию
Обсуждают сегодня