зарплата моряка офицера в финской армии 4к. у тебя будет 5к и выше за макака кодинг. тебе че мало чтоль. ответственности ноль а зарплата выше чем у моряка-военного.

про математиков и датасаентистов есть неплохая картинка иллюстрирующая их скиллы вполне доходчиво. без обид только :)

А причем тут математики? Я готов обсуждать эти вопросы предметно с человеком, аккуратно прочитавшим "от корочки до корочки" книжку Ширяева "Вероятность". Прости, но в противном случае ты говоришь в достаточно резкой и безапелляционной форме о скиллах, о которых не имеешь особо понятия.
То, что в области дофига людей, ничего в ней не понимающих, имеет ровно те же причины, что и толпы оболтусов от ИТ в принципе: всем хочется в быть в тренде.

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

Я доктор физ.мат. наук, я пишу на С++ и ASM, HLSL и по необходимости всякую муть на C#. Прототипирую на Python3, Julia, MATLAB и еще на всем, на чем скажут. Помимо этого, математическим аппаратом пользуюсь почти каждый день. Так что мне смешно читать про excel и "скилы главбухов". Так что нет, "любой программист" не может это делать в отношении меня.

увоили ровно через 6 месяцев за что они так?

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

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

расскажи как легко и быстро вытащить уникальные записи из 2 миллиардов элементов если ты ограничен по памяти и по процу?

ты же знаешь си++ и питон с асмом. для тебя это не должно быть проблемой.

В смысле, настоящий доктор? Сначала кандидатскую защищали, а потом и докторскую? С соответствующими оппонентами?

Ты плохо задачу поставил. Какого рода данные прежде всего? И какого рода ограничения? Как часто обращаются к данным? Почти всегда такого рода задачи можно решить, структурируя исходник. Скажем, построив хэши или структурировав исходник в сбалансированное дерево, как это делают в некоторых файловых системах. Если к данным обращаются часто, то можно делать приоритетную очередь, например. Много вариантов, детали нужно уточнять.

Нет, местного разлива, к сожалению.

Первое что вспомнил - как Дэвид Малан «издевается» над телефонным справочником 😀

А мне вот интересно, почему каждая тема про IT приводит к замерам писунов у программистов?

Это такая отличительная особенность программистов, надо постоянно мериться и доказывать что у него лучше, чем у других?

да отсортировав и потом проитерировав выбрасывая повторения. классика литкода. а теперь представь что тебе не лезет в память больше 10% этого списка.

про алгоритмы сортировки тоже можем пообщаться. особенно в разрезе что больше 10% списка тебе в память не лезет. но ты можешь использовать например, брокер сообщений.

про хеши не понял- что будем хешировать и зачем.

потому что не только лишь все - докторы, знающие асм. а есть и мартышки программирующие программы на всяких явах.

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

IT состоит не только из программирования, есть еще много всего интересного.
А вот программирование как троянский конь.

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

Как бы то ни было, я не планировал сраться на тему "нужности" или "ненужности" тех или иных знаний. И я не считаю программистов на Java "мартышками". Уверен, они часто знают многие нужные и полезные вещи, которых не знаю я. Но и обобщения на тему "ненужных корочек" и "специалистов по экселю" - это, прости, перебор.

так я не разговариваю с тобой на птичьем языке. я к тебе как к Доктору обратился за помощью вот с такой вот проблемой. данные же ведь. дата. саенз. анализ. и те де и те пе.

Давай разбираться: ты утверждаешь, что у тебя 2 миллиарда записей, из которых в память тебе помещается не более 10% и ты из них хочешь сформировать список без повторений? Я правильно тебя теперь понял?
Например, можно считать SHA, загружая элементы потоком. Из получившихся значений SHA формируй хэш-таблицу и выкидывай себе повторения.
Впрочем, если твои данные никак не структурированны, то от необходимости считать SHA для каждого элемента ты не убежишь. Более того, один элемент может быть очень большим и SHA может быть считать долго, тогда это уже другая история.
Если знаешь какой-то очень эффективный способ, с удовольствием почитаю.

при таких объемах не боишься что ша начнет коллизии давать например? сколько там 2 в 160й степени вроде вариантов. 2 миллиарда записей. сколько раз надо прогнать 2 миллиарда условно разных записей, где дубликатов скажем, 10%, чтоб нарваться на коллизию когда два разных объекта дадут один хэш и мы потеряем данные потому что один из элементов выбросили?

правльно подобрать коэффициенты тоже мастерство . :wisdom: плюс знание статистики и общий ИИ кругозор которого у 'макак' может и не быть....

да. согласен. я тоже где то читал книжку что действительно РАНДОМНЫЕ числа придумать та еще проблема. и надо иметь высокий кругозор чтоб их придумывать.

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

чот звучит как не смог влиться в коллектив. ну бывает. жаль. а что с другими то местами? я все же не пойму ты программист или датасаентист

Желаю успехов в поиске колизии SHA-256 :sla:. Это 2^256 вариантов. 2 миллиарда - это ~2^31. Таким образом, тебе, чтобы на практике нарваться на коллизию однозначно, потребуется прогнать 2^225 списков из двух миллиардов разных данных. Даже, если бы каждая запись занимала бы 1 байт (что делало бы борьбу с коллизиями, да и просто загрузку массива в память относительно тривиальной задачей), то все вместе это бы составляло поток данных из 2^226GiB. Для сравнения, объем всего интернета составляет 40*10^12GiB по оценкам на 2020 год.
Конечно, практическая вероятность встретить коллизию несколько выше (хотя, насколько мне известно, для SHA-256 ее до сих пор не нашли).

ну 2 миллиарда записей где всего один байт на запись ты ж понимаешь там всё просто делается перебором. или пока до конца списка не дошли или пока 256 элементов не выбрали - что раньше. итого комплексити о эн. можно распараллелить легко. можно на куски разбить легко.
ну ок. хорошо что можно почти не беспокоиться за коллизии. и да.. я не думал что вероятность умеет НАКАПЛИВАТЬСЯ. типа купил миллион лотерейных билетов - гарантированно получил выигрышный. хотя ты Доктор - тебе виднее.
в любом случае к решению задачи мы пока не приблизились. давай думать дальше. вот как программисты а не математики. какие нам могут помочь инструменты или подходы, чтоб это просчитать? согласен по ша - он поможет (наверное) сэкономить память если исходная запись больше чем 160 бит (или 256?), он поможет срезать ее до этих размеров.

Имлементил я надавно фичу и использовал SHA-256 чтобы искать дупликаты в данных. Думаю ох если коллизия будет не будет работать мой алгоритм. А потом еще раз подумал и наверное через миллиард лет когда коллизия случится мне будет все равно. И плюнул думать такие мысли.

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

Сотни терриков? Это гдето в параллельной вселенной. Ну или в Гугле :lol:

для тебя сотня териков кажется много? ну окей.

Для меня много. Я думаю для 99% бизнеса в Финляндии это много. Даже для 99.99%

Причем тут накопление? Я тебе нижнюю оценку посчитал, исходя из предположения, что тебе нужно иметь 2^256 + 1 разных записей, чтобы гарантированно получить хотя бы одну коллизию. Если хочешь с вероятностями, пожалуйста:
вероятность коллизии для SHA256 оценивается, как 4.3*e-60. Для того, чтобы получить коллизию с вероятностью 0.1%, тебе надо будет прогнать log(4.3*e+57)/log(1-4.3e-60) повторений. Это практическая бесконечность, сколько бы "террабайтов" ты не гонял. Так что по сути SHA256 здесь не только "уменьшает объем памяти", необходимый для хранения одного элемента, но и позволяет легко вытащить уникальные элементы из списка (поскольку сравнивать ты будешь только 256-битные числа, а знать, из каких элементов они получились, можешь, тривиально храня ссылку на исходную запись вместе с хэшем).
Сложность будет в любом случае O(n), если в данных отсутствует структура. Если очень хочется, то можно это примитивно распараллелить, разбивая на куски и сливая промежуточные результаты. Это уже совсем скучно.
Ну, если совсем паранойя насчет коллизий, то можно сделать perfect hashing.

По выделенному: в чем именно задача выглядит нерешенной? И о каких еще интструментах идет речь. Если поговорить о библитеках и фреймворках, то это не со мной, т.к. эта ерунда вообще обсуждения не стоит и подбирается, исходя из контекста решаемой задачи.

Мне как инженеру вообще важнее откуда дата читается, в каком формате, и как ее потом обрабатывать зависит именно от этого. :)

Я не думаю что есть фреймворки, которые помогут тебе решить эту задачу. Я имею ввиду так что положил - достал. Задача выглядит нерешенной в том что никаких внятных предложений кроме а давай захешируем и ещё и хеши будем хранить вдовесок к данным зная что у нас памяти нема.
Вот видишь, ты математик и доктор а мартышкины задачи вызывают у тебя затруднения...

Да потому чо ты как дурачек конкретики не даёшь. Это тоже самое что я тебя сейчас спрошу как миллиардер заработать. А ты мне скажешь биткойны надо было покупать или майнить:)

Если честно, то я не понимаю, где именно ты увидел затруднения. Мне ясно, что тебе очень хочется продемонстрировать, как "математики и доктора не умеют в программирование" (вопрос только, а зачем тебе это?). Пока же ты лишь продемонстрировал, что не понимаешь (или специально не хочешь понимать), что такое сравнение по хэшу и как таким образом твою задачку можно абсолютно тривиально решить (по крайней мере, в тех очень общих и туманных условиях, которые ты задал).
P.S. У меня не было и нет абсолютно никакого желания воевать, но ты уж сильно перегибаешь с обобщениями.

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

тоесть теперь в уравнении появляюстя базы, ну тогда проблема вооще проподает:)

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

Совершенно не очевидно, можно например кровлить интернет или читать какой нибудь
стрим. Тут тоже кстати важен формат информации.

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

Он прав в том что задача вещь относительная, как всё наше бытие:)

я чуть выше сказал про инструменты и про то что это не черный ящик куда взял-положил. если в память не лезет то что толку хеши считать ты верно заметил, что в зависимости от типа данных это сэкономит память или не сэкономит. но даже 256 бит или сколько там + издержки помноженное на 2 миллиарда это всё-равно много.
про инструменты опять же.. ну во-первых, какие. во-вторых, всё-равно НЕТ инструмента чтоб переложить в него два лярда записей в один конец трубы и получить х записей в другом. надо сделать ЧТО-ТО с ЧЕМ-ТО.

кстати, добавление элемента в хэш-карту с равномерным распределением емнип не Н а 1 сам процесс добавления через итерацию разумеется Н.

Достал, посчитал хэш, засунул в словарь вместе со ссылкой на исходную запись. Если такой ключ (хэш) в словаре уже есть, значит дубликат, идём дальше. Обработанный элемент выгружаем из памяти, переходим к следующему. Здесь исхожу из посылки, что хотя бы один элемент за раз в память влазит. В итоге будет в словаре список ссылок на недублирующиеся записи. Это решает задачу в том виде, в котором ты ее сформулировал.
А инструмент в твоём случае - это база данных, дистинкт в которой реализует решение собственно задачи. Очень нетривиально реализует, если база распределённая.

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

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

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

Че вы спорите? Спросите у Ивана Петровича. Он вам все разъяснит.

Тебе уже выше сказали, что весь интернет по оценкам на 2020 год - это всего 40 зеттабайт. Это 10^21 байт порядок. А нарваться на коллизию для sha256 с вероятностью 0.1% тебе порядка 10^60 повторений нужно будет. У сравнения по хэшу проблема в том, что он со временем деградирует. Но насколько это проблема, зависит от области применения.

проблемы только у нас, клиенты спят спокойно, так как ночью надо это делать:)

ты видиш мой палец?

Найдешь чего то еще, если образование есть. Главное, не заниматься дауншифтингом и искать высококвалифированную работу. Я смотрю на своих приятелей со студенческих времен, у меня денег не было, у них были, потому что они подрабатывали где-то на стройках или охраниками, до сих пор там работают.

Вот у меня очередной заход этой весной был. Подавала на позиции Data Analyst/Data Engineer. Получила с десяток реджектов сразу, пару интервью, один рекрутинговый процесс тянется до сих пор, но я настроена пессимистично. Они меня поймали телефонным звонком у школы сына без какого-либо согласованного заранее времени и прогнали по анкете навыков. Крупная консалтинговая контора.

Вам византийский вариант, или обычный ?

Мне оба, и лучше на примерах, как применяют, и для чего можно применять в принципе.

Тогда будет простой Raft.

Группа старых друзей-алкоголиков в пятницу вечером думает не пойти ли им выпить (прийти к консенсусу).
У каждого из них есть своя более-менее голова, но нет телепатических способностей, любое сообщение от одного к другому требует конечного времени (распределенный консенсус).

В группе есть свой лидер - выбранный и признанный остальными участниками, но принципиально от них не отличающийся (его могут и переизбрать, если есть серьезный повод. Новым лидером может стать любой другой собутыльник).
В обычный день лидер каждому сообщает идут они сегодня пьянствовать или нет. Остальные его внимательно слушают и кивают если поняли команду. Как только лидер увидел что больше половины кивков получено, решение принято - есть консенсус. Если больше половины поступят так как лидер сказал - все отлично.

Дальше, в группе могут появляться новые алкоголики, нужно уметь учитывать их число и кивки.
Из группы могут по-одному вываливаться участники (например, потому что печень). Нужно уметь их исключать. Даже если вдруг захотел вывалиться лидер.
Часть участников группы может застрять в лифте, и не участвовать в кивании. Лидеру нужно уметь не обратить на них внимание, организовать пьянку без них.
И самый интересный случай - в лифте может застрять более половины группы. Они должны понять что команд от лидера не поступает, и выбрать себе нового лидера. Старый тоже должен понять что он слишком мало кивков видит - и он уже не лидер, а обычный алкаш и снова вписывается в коллектив.

Собственно Raft - машина с небольшим числом состояний, которая позволят каждому участнику группы знать в каком он статусе (лидер, самовыдвиженец или рядовой алкоголик), объясняет как выбирается новый лидер, так чтобы он оказался единоличным, признанным, и выбирался в короткое время.
Сложности: строго говоря состояний у этой машинки бесконечное количество. Кроме роли участника у него есть еще таймер, порядковый номер лидера и генератор случайных чисел.
Но в целом алгоритм не сложный.

Paxos: цель та же - договориться идем вечером пить пиво или нет, но без явного лидера. И вообще алгоритм сложнее, хотя и старее, с несчетным числом тонкостей (и я его не помню.)

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

Старый политический анекдот про решения правительства.
- Они уже месяц не могут решить что делать, спросили бы у Рабиновича.
- У какого Рабиновича?
- Да у любого.

А почему реджекты? Что то говорят? Может нет опыта и тп?

говорят, как обычно
We received many good applications, which we have now processed. After careful consideration, we regret to inform you that you have not been selected to move on to the next step.
на этом все.
а про опыт... так в России 152ФЗ, где ж мне взять столько лет с основными облачными вендорами