да

Друзья, как канонично в скале Double округлять?

я объявляю где-нить на задворках RoundingUPMathContext и тащу его в каждое место, где что-то округляю

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

1. Что если дубль пролезет? Так ли это страшно? 2. Насколько часто в потоке есть данные вида (предположим, что все поля составляют индекс): Foo(a1, b1, c1) Foo(a1, b2, c1) // отличается одним полем Foo(a1, b2, c2) // отличается двумя ? Я к тому, что мб можно как-то сделать так, чтобы вероятность ложноположительного срабатывания была приемлема

правда это с BigDecimal ☺️

У биг десимал апи понятный

У биг десимал апи понятный

джавовский или скаловский ?

оба; но я говорил про скалу

но если те дока нужна будет по типам округления то придется лезть в джава доку; в скале нет ничего (не было, на данный момент хз)

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

можно сделать multi level map

он же multiindex

начиная с компонент ключа с максимальной кардинальностью

можно продолжить идею и сделать на некоторые ключи с большой кардинальностью prefix tree

https://github.com/rklaehn/radixtree

к сожалению не пойдёт, все значения из ключа с большой вероятностью могут не повторяться или повторяться очень редко

Такие деревья хороши тем, что они помимо скорости работы на уровне хешмапов, ещё сохраняют порядок и компрессят фактически множетсво ключей

к сожалению не пойдёт, все значения из ключа с большой вероятностью могут не повторяться или повторяться очень редко

Тогда https://en.wikipedia.org/wiki/Bloom_filter

он не деёт гарантии

не даёт, но хорошо работает, когда большинство проверок негативные и редко нужно лезть в холодное хранилище за последней проверкой

какая частота у вас положительных и отрицательных ответов?

дубликат - это ошибка, вероятность мала, холодного хранилица нету по сути

Хмм, ну хешируйте murmur 128

128 бит на ключ вы можете себе позволить хранить?

да, но это же не защитит от хэш коллизий?

да, но это же не защитит от хэш коллизий?

иммолейшн 128 бит импрувед. вероятность резиста крайне мала

благодарю, интересно

ну т.е. это эквивалентно коллизии UUIDов

мало кто от неё прямо защищается

благодарю, интересно

т.е. это все повторения все тех же предложений которые я на десяток сообщений выше указывал) видимо со второго раза в этом чатике лучше заходит)

т.е. это все повторения все тех же предложений которые я на десяток сообщений выше указывал) видимо со второго раза в этом чатике лучше заходит)

можешь сравнить твои формулировки и мои и понять, почему твои прошли мимо сознания собеседника

да норм, я всё принял, нужно подумать, всем спасибо

Если ты говоришь мимоходом "древовидные ключи" никто не понимает о чём ты говоришь. Если ты говоришь "отображать в лонг", мало кто догадается, что ты имешь в виду не 64, а 128 бит и хеширование

Идеи пришли в голову в таком же порядке в виде такого же супа. Но я взял сам за себя ответственность разобрать этот суп, выстроить его в последовательность, и дополнить ссылками и описанием

Если ты говоришь мимоходом "древовидные ключи" никто не понимает о чём ты говоришь. Если ты говоришь "отображать в лонг", мало кто догадается, что ты имешь в виду не 64, а 128 бит и хеширование

Мне не понять, почему люди больше доверяют умным словам нежели простым железобетонным описаниям) И я говорил привести к одному числу с отображением 1 к 1 без дубликатов

к одному числу без дубликатов привести - насколько большим будет это число для Long, LocalDateTime, BigDecimal? :)

к одному числу без дубликатов привести - насколько большим будет это число для Long, LocalDateTime, BigDecimal? :)

без доп данных. больше всего зависит от свойствбигдецимал зависит. может там у тебя инт с аски лимитами, хоть и в бигдецимале)

Привести к числу без дубликатов - это другое название для компрессии

long = 8, localdatetime - 4 или 8 (не помню), бигдецимал - соответственно понимать характер данных надо - это в грубом подсчете. А еще может у тебя там локалдейттайм - вего несколько дней (хоть и время разное) - тоже можно сократить (это уже про то, что Олег кардинальностью назвал)

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

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

ну компрессия скорее всего эффективней хеширования во всём

вариант - конкатенировать в строку и сжать?

вариант - конкатенировать в строку и сжать?

Нет, скорее нужно продумывать вариант для каждого типа отдельно

К примеру, с 99.999% вероятностью дата - это день, месяц и год в 10-летнем диапазоне

Тогда её можно закомпрессить в 12 бит

я понял

Для каждого типа можно первым(и) битом(ами) -индикаторами обозначать насколько хороший вариант

тогда получится компрессия с плавающей длиной

Ещё если есть корреляция между датой и числом

Можно компрессить не только сами значения, а придумать двух-уровневую структуру, на первом уровне кодировки значений, на втором - сжатые кодировки диффов

Это может быть эффективнее префиксных деревьев

нормального описания я не найду, но какую-то интуицию как хранить диффы и диффы диффов для дат и чисел можно получить отсюда http://www.vldb.org/pvldb/vol8/p1816-teller.pdf

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

https://github.com/npgall/cqengine

у меня акка стримы

И

засейвлено

а поли по копродукту это нормально в скале?

нормально) но только не стоит тащить поли в юзер апи

эсли мы про шаплез

а поли по копродукту это нормально в скале?

а запах по вкусу это нормально в сознании?

ты пробегаешься по копродукту или матчишь копродукты?

в любом случае поли не нужны

ты пробегаешься по копродукту или матчишь копродукты?

хочу мап по типу в копродукктте сделать

да напиши тайп класс прост который сделает что надо

Котаны, а что вас удерживает от использования Королева?

Отсутствие любой внятной документации на момент знакомства. Обсуждали на совещании, т.к. с лифтвеб есть вопросы. Но кто-то сказал "тут нет даже вменяемого HW" и тут же перешли на другие

Отсутствие любой внятной документации на момент знакомства. Обсуждали на совещании, т.к. с лифтвеб есть вопросы. Но кто-то сказал "тут нет даже вменяемого HW" и тут же перешли на другие

А сейчас доки ок?

Отсутствие любой внятной документации на момент знакомства. Обсуждали на совещании, т.к. с лифтвеб есть вопросы. Но кто-то сказал "тут нет даже вменяемого HW" и тут же перешли на другие

А что такое HW?

А сейчас доки ок?

а сейчас уже и не нужно, вроде :( А они появились?

HelloWorld

хочу мап по типу в копродукктте сделать

делай

а сейчас уже и не нужно, вроде :( А они появились?

Да, довольно подробная дока. https://fomkin.org/korolev/user-guide.html

К слову HelloWorld всегда были. В ридми была ссылка https://github.com/fomkin/korolev/tree/master/examples с примерами для всего что есть в Королеве.

делай

спасибо

для хаскелля есть что-то аля скала индекс?

нашел

https://github.com/RMSone/slick-cats/releases/tag/v0.7-MF

#toxic

http://www.opennet.ru/opennews/art.shtml?num=47072

#toxic

cats родилась также

rabbits.js

из-за код оф кондакт? О_0

cats родилась также

из-за код оф кондакт? О_0

из-за разногласий / "превышения полномочий" / и т.п

что там в slick-cats?

https://yandex.ru/korolev/

С подключением!

Ник подходящий reactivemaster

Типа, 2 дня назад это настолько давно? :)

да тут прост уже два дня утро с этой ссылки начинается)