Программирование[11]

чел, ты бы хоть имплементацию посмотрел прежде чем пиздеть

там буквально твой же код, только возвращает результат сетовой операции, а не тру/фолс

я вообще в ахуе, что ты выдал асимптоматику по сигнатуре функций

видимо у тебя листА и листБ это нечто иное

Ого, оказывается, пройти по сету - это O(n). Вот день открытий полных чудный.

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

Kant написал 1 час назад:

чел, ты бы хоть имплементацию посмотрел прежде чем пиздеть

там буквально твой же код, только возвращает результат сетовой операции, а не тру/фолс

 

я вообще в ахуе, что ты выдал асимптоматику по сигнатуре функций

видимо у тебя листА и листБ это нечто иное

Нахуя мне смотреть имплементацию, если метод работает с ИТЕРАТОРАМИ блять.

В java collectionA.removeAll(collectionB) вызывает contains() на collectionB который для хэшсетов O(1)

Grohuf написал 3 минуты назад:

Ого, оказывается, пройти по сету - это O(n). Вот день открытий полных чудный.

Пройти да, проверить есть ли элемент в хэш-сете - O(1) епта

Index написал 4 минуты назад:

Пройти да, проверить есть ли элемент в хэш-сете - O(1) епта

А ты знаешь, как устроены хэш-сеты?

Grohuf написал 7 минут назад:

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

@grok это правда?

Нет, это неправда. В общем случае пересечение двух массивов не быстрее пересечения двух сетов. Наоборот — пересечение сетов почти всегда намного быстрее.

Когда массивы теоретически могут выиграть

Только в очень специфических случаях:

Массивы уже отсортированы → можно сделать O(n + m) двумя указателями без доп. памяти.

Элементы — только маленькие целые числа (0..1000), и можно использовать битовые массивы или счётчики.

Объёмы данных совсем крошечные (десятки элементов) — тогда константы перевешивают асимптотику.

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

Но в 99 % обычных задач (особенно когда массивы содержат строки, объекты, большие числа, UUID и т.д. — превращение в set и пересечение через него будет на порядки быстрее.

Grohuf написал 3 минуты назад:

Index написал 8 минут назад:

Пройти да, проверить есть ли элемент в хэш-сете - O(1) епта

А ты знаешь, как устроены хэш-сеты?

Неа, расскажи пожалуйста 

Index написал 3 минуты назад:

Grohuf написал 14 минут назад:

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

@grok это правда?

 

Нет, это неправда. В общем случае пересечение двух массивов не быстрее пересечения двух сетов. Наоборот — пересечение сетов почти всегда намного быстрее.

Когда массивы теоретически могут выиграть

Только в очень специфических случаях:

Массивы уже отсортированы → можно сделать O(n + m) двумя указателями без доп. памяти.

Элементы — только маленькие целые числа (0..1000), и можно использовать битовые массивы или счётчики.

Объёмы данных совсем крошечные (десятки элементов) — тогда константы перевешивают асимптотику.

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

Но в 99 % обычных задач (особенно когда массивы содержат строки, объекты, большие числа, UUID и т.д. — превращение в set и пересечение через него будет на порядки быстрее.

Grohuf написал 6 минут назад:

Index написал 11 минут назад:

Пройти да, проверить есть ли элемент в хэш-сете - O(1) епта

А ты знаешь, как устроены хэш-сеты?

Неа, расскажи пожалуйста 

ого. АИшка оказалась умнее тупого юзера с ПД и знает случаи, когда массив бывает быстрее.

Плохо, что ты не знаешь устройство хэш-сетов. Иначе не порол бы хуйни.

Grohuf написал Только что:

Плохо, что ты не знаешь устройство хэш-сетов.

А ты про какие хеш-сеты? На цепочках или на открытой адресации? С множественным хэшированием? А может про вероятностные?

У тебя лист может быть задизайнен всратее сета.

А какой-нибудь EnumSet может быть на битовой маске, где пересечение находится битовым &, тупой уебан 

Index написал 2 минуты назад:

Grohuf написал 6 минут назад:

Плохо, что ты не знаешь устройство хэш-сетов.

А ты про какие хеш-сеты? На цепочках или на открытой адресации? С множественным хэшированием? А может про вероятностные?

 

У тебя лист может быть задизайнен всратее сета.

А какой-нибудь EnumSet может быть на битовой маске, где пересечение находится битовым &, тупой уебан 

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

Just.Doit написал 29.11.2025 в 01:20:

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

 

какие там размеры листов?

кек, я сходу подумал, что видимо сильно чего-то не догоняю. в плане откуда без хэша может m+n взяться

пересечение одного массива с другим получается O(n+m) исключительно через хеш таблицу. в противном случае там неотсортированные данные и пизда (либо сортировать - пизда, либо квадрат для неотсортированных данных, конкретнее m*n)

sB.Raven написал 10 часов назад:

Index написал 27.11.2025 в 03:54:

Как писал один чувак в своем тг канале

Цитата

 тут будет очень интересная хуйня - я тут играюсь с этой антигравити и прямо ссусь в процессе как она помогает. Помогает не тратить время на всякую хуйню - я решил поиграться с Яндекс Serverless Containers + graal + Java 25. И я вечера три наверно убил на то, чтобы собрать hello world - микронавт где-то в гредле валился, boot на запуске нативки, и только кваркус по доке собрался и заработал.

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

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

И вот реально для прототипирования платформенных задач, интеграций эта хуйня очень хороша.

 

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

 

И собственно где тут СТАЖЕРСКИЙ скоуп задач? Стажер будет это пол года делать и потом занесет себе на пол страницы CV в достижения как он все поднял и настроил.

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

 ты приходишь на проект - и будешь заниматься проблемами бизнеса. Кто это будет - стажер или сеньор, бизнесу поебать

sB.Raven написал 10 часов назад:

Index написал 10 часов назад:

sB.Raven написал 10 часов назад:

бизнесу поебать

Бизнесу не поебать сколько это стоит бабок и сколько времени будет разрабатываться фича.

ну да, поэтому индусы победили в ит....  если ты не индус - готовый работать 24на7 за карри похлебку, то что ты делаешь в ит....? это риторический вопрос

 

sB.Raven написал 9 часов назад:

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

 

бизнесу поебать  бизнесу поебать

бизнесу поебать  бизнесу поебать

индус за карри похлебку стал реальным сеньором

а бизнесу поебать бизнесу поебать

а бизнесу поебать бизнесу поебать

что рейвен тупой ебанат бизнесу поебать

я лутаю 7 нулей за пару лет но бизнесу поебать

бизнесу поебать бизнесу поебать

что индус за карри похлебку стал реальным сеньором

а рейвен тупой ебанат бизнесу поебать

рейвен рейвен научи меня жить как поднять лаве

в чем твой успеха секрет? нужно просто повторять 

что бизнесу поебать бизнесу поебать

что рейвен тупой ебанат бизнесу поебать

вот как тут срач устроили у мнея так раз в 2 недели планирование

2 синьора сидят срутся по поводу бизнес фич по 2 часа

madvlaydin написал 1 час назад:

вот как тут срач устроили у мнея так раз в 2 недели планирование

2 синьора сидят срутся по поводу бизнес фич по 2 часа

хороший митинг

madvlaydin написал 1 час назад:

2 синьора сидят срутся по поводу бизнес фич по 2 часа

а чем там сраться зачем, темболее синьерам?

приоритет от продакта и погнали делать

Index написал 10 часов назад:

Kant написал 11 часов назад:

чел, ты бы хоть имплементацию посмотрел прежде чем пиздеть

там буквально твой же код, только возвращает результат сетовой операции, а не тру/фолс

 

я вообще в ахуе, что ты выдал асимптоматику по сигнатуре функций

видимо у тебя листА и листБ это нечто иное

Нахуя мне смотреть имплементацию, если метод работает с ИТЕРАТОРАМИ блять.

В java collectionA.removeAll(collectionB) вызывает contains() на collectionB который для хэшсетов O(1)

 

Grohuf написал 10 часов назад:

Ого, оказывается, пройти по сету - это O(n). Вот день открытий полных чудный.

Пройти да, проверить есть ли элемент в хэш-сете - O(1) епта

ты долбоеб?

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

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

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

Kant написал 37 минут назад:

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

А ну получается в сисярпе для пересечения создаются хэшсеты под капотом? Классно, вот бы не создавать хэшсеты по итератору коллекции которая уже и так хэшсет 

Вообще пересечение можно трактовать по разному. 

С учетом дубликатов или только уникальные значения например.

Мой оригинальный тейк был про list.removeAll(collection) в java  

Как реализовано пересечение в сисярпе меня не ебет.

Но добавлю следующее.

С точки зрении асимптотической сложности 

func() {
for(1 .. n) { /*O(1) operations*/ }
for(1 .. n) { /*O(1) operations*/ }
for(1 .. n) { /*O(1) operations*/ }
}

и

func() {
for(1 .. n) { /*O(1) operations*/ }
}

Эквивалентны O(n)

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

Хотя опять же, тут могут быть нюансы, где 

func() {
for(1 .. n) { /*O(1) SIMD code*/ }
for(1 .. n) { /*O(1) SIMD code*/ }
for(1 .. n) { /*O(1) SIMD code*/ }
}

предпочтительнее 

func() {
for(1 .. n) { /*O(1) non-SIMD code*/ }
}

Index написал 1 час назад:

вот бы не создавать хэшсеты по итератору коллекции которая уже и так хэшсет 

там не итератор

Index написал 2 часа назад:

Kant написал 2 часа назад:

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

А ну получается в сисярпе для пересечения создаются хэшсеты под капотом? Классно, вот бы не создавать хэшсеты по итератору коллекции которая уже и так хэшсет 

Вообще пересечение можно трактовать по разному. 

С учетом дубликатов или только уникальные значения например.

Мой оригинальный тейк был про list.removeAll(collection) в java  

Как реализовано пересечение в сисярпе меня не ебет.

 

Но добавлю следующее.

С точки зрении асимптотической сложности 

func() {
for(1 .. n) { /*O(1) operations*/ }
for(1 .. n) { /*O(1) operations*/ }
for(1 .. n) { /*O(1) operations*/ }
}

и

func() {
for(1 .. n) { /*O(1) operations*/ }
}

Эквивалентны O(n)

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

Хотя опять же, тут могут быть нюансы, где 

func() {
for(1 .. n) { /*O(1) SIMD code*/ }
for(1 .. n) { /*O(1) SIMD code*/ }
for(1 .. n) { /*O(1) SIMD code*/ }
}

предпочтительнее 

func() {
for(1 .. n) { /*O(1) non-SIMD code*/ }
}

 

кто из listA или listB в твоем коде является хэшсетом?

Just.Doit написал 3 часа назад:

madvlaydin написал 5 часов назад:

2 синьора сидят срутся по поводу бизнес фич по 2 часа

а чем там сраться зачем, темболее синьерам?

приоритет от продакта и погнали делать

 

синоёра я имею ввиду сильных технически и бизнесовых разраба

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

второй имплементирует фичи/архитектуру и дрочится насчёт узких мест и тому подобного

вопрос присутствующим

какими знания должны обладать линии l1-l2?

если l3 - sre, l4 - разработка

godspeed написал 56 минут назад:

вопрос присутствующим

какими знания должны обладать линии l1-l2?

 

если l3 - sre, l4 - разработка

в моём мире поддержка должна как минемум читать ченжлоги поставок на прод

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

ну а если они еще и логи будут знать где и какие смотреть, то это прям имба ебаная