функция из второй задачи находит же не оптимальное решение, а просто хорошее, а в третьей нужно найти именно минимальное значение и поэтому её нельзя использовать? Или я не понял?
@@werft2266 Вроде по условию не подразумевается, что мы заранее знаем все емкости, то есть не получится сделать минимальное количество бидонов. Ну и в третий аналогично - последовательность бидонов менять нельзя
3 задача была с неправильным примером, там не 12 можно распределить так: 4 2 5 | 2 8 | 3 4 3 | 1 10 | Вот код задачи: conv = [1, 3, 2, 4, 10, 8, 4, 2, 5, 3] count = 4 # с сумматорами # CPU - O(n*m) n - кол-во емкостей в конвейере, m - кол-во контейнеров # Memory - O(m) - тк используем список сумматоров summators = [0 for i in range(count)] minSumIndex = 0 for e in conv: for i in range(len(summators)): if summators[minSumIndex] > summators[i]: minSumIndex = i summators[minSumIndex] += e print(max(summators))
У них в условии 3 задачи порядок элементов нельзя менять (это было в условии 2 задачи, для 3 не очевидно, но это типа модификация 2). Но решение таки не всегда верное, после нахождения нужно еще попробовать уменьшать объем на 1, пока это возможно, тк с текущим количеством бидонов может быть диапазон объемов.
@@RomanKoshetov У них емкости идут в порядке 1 3 2 4 10 ... Нельзя залить, например, 1 3 в первый бидон, потом 2 во второй, а затем 4 снова в 1. Если перешли к заполнению второго бидона, то первый более не трогаем. Из-за этого задача проще, чем искать оптимальное распределение. То есть исходный пример [1, 3, 2, 4, 10, 8, 4, 2, 5, 3] распределяется только с сохранением порядка [1, 3, 2, 4 | 10 | 8, 4 | 2, 5, 3]
У таких ребят, как Яндекс, Амазон, спотифай, Гугл и тд, работающих с большим количеством пользователей, данных, стримингом и потоками трафика критически важно
@@spacecookies6814 имеешь в виду что это именно для хайлоада? Просто там пузырьковая или другая сортировка вручную практически нигде не применяется) разве что совсем у низкоуровневых сишников. В промышленных системах важнее знать особенности разных типов индексов конкретных СУБД, архитектурные подходы... Подправьте если не прав. Даже те кто работает в долине наизусть учат алгоритмы и структуры данных для собесов, а потом все как один говорят, что это можно забывать до следующего поиска работы
Просто это копирование ЗАПАДНОГО подхода к набору персонала в КРУПНЫЕ компании (Google, Amazon, Facebook и т.д.): важно чтобы КАНДИДАТ был достаточно эрудирован (уже встречал подобные задачи и мог быстро решить предложенную) или был сообразителен и мог быстро предложить алгоритм шенеия и оценить его плюсы и минусы.
Когда чел шарит в алгоритмах, он не будет решать реальные задачи не оптимально. Я на практике у людей, не умеющих решать алгоритмические задачи часто вижу код с неоправданно завышенной асимптотикой. Негативных следствий из этого много разных. Например, какие-то запросы серверу могут долго обрабатываться. Может потребоваться сильно больше серверов или более дорогих серверов для обеспечения работы такого решения, чем для обеспечения работы оптимального решения. Это такая тренировка специалиста с запасом. Такой подход в любой сфере жизни можно увидеть. Тяжело в учении -- легко не работе.
Павел - молодец! 🎉
после поиска первого решения через бин поиск нужно итеративно - = 1 спускаться до минимума, koko eats bananas таки
Ваня, привет от 50 когорты! 😁
функция из второй задачи находит же не оптимальное решение, а просто хорошее, а в третьей нужно найти именно минимальное значение и поэтому её нельзя использовать?
Или я не понял?
Во второй решение за линию, вполне оптимальное
@@maxfalkovich в плане не минимальное количество контейнеров
@@werft2266 Вроде по условию не подразумевается, что мы заранее знаем все емкости, то есть не получится сделать минимальное количество бидонов. Ну и в третий аналогично - последовательность бидонов менять нельзя
3 задача была с неправильным примером, там не 12 можно распределить так: 4 2 5 | 2 8 | 3 4 3 | 1 10 | Вот код задачи:
conv = [1, 3, 2, 4, 10, 8, 4, 2, 5, 3]
count = 4
# с сумматорами
# CPU - O(n*m) n - кол-во емкостей в конвейере, m - кол-во контейнеров
# Memory - O(m) - тк используем список сумматоров
summators = [0 for i in range(count)]
minSumIndex = 0
for e in conv:
for i in range(len(summators)):
if summators[minSumIndex] > summators[i]:
minSumIndex = i
summators[minSumIndex] += e
print(max(summators))
У них в условии 3 задачи порядок элементов нельзя менять (это было в условии 2 задачи, для 3 не очевидно, но это типа модификация 2). Но решение таки не всегда верное, после нахождения нужно еще попробовать уменьшать объем на 1, пока это возможно, тк с текущим количеством бидонов может быть диапазон объемов.
@@dezmondlab мое или их решение не верное?
@@RomanKoshetov у них неверное
@@dezmondlab немного не понял про неизменение порядка, в моем решении мы идем циклом по каждому по порядку их следования в массиве, можете объяснить?
@@RomanKoshetov У них емкости идут в порядке 1 3 2 4 10 ... Нельзя залить, например, 1 3 в первый бидон, потом 2 во второй, а затем 4 снова в 1. Если перешли к заполнению второго бидона, то первый более не трогаем. Из-за этого задача проще, чем искать оптимальное распределение.
То есть исходный пример [1, 3, 2, 4, 10, 8, 4, 2, 5, 3] распределяется только с сохранением порядка [1, 3, 2, 4 | 10 | 8, 4 | 2, 5, 3]
А что помешало очень большую емкость разлить по нескольким бидонам?
Мне с лососем, пожалуйста. Спасибо
Можете кто-нибудь объяснить, на кой хрен такие задачи, если в реальной работе никогда даже близко к ним не бывает?
У таких ребят, как Яндекс, Амазон, спотифай, Гугл и тд, работающих с большим количеством пользователей, данных, стримингом и потоками трафика критически важно
@@spacecookies6814 имеешь в виду что это именно для хайлоада? Просто там пузырьковая или другая сортировка вручную практически нигде не применяется) разве что совсем у низкоуровневых сишников. В промышленных системах важнее знать особенности разных типов индексов конкретных СУБД, архитектурные подходы... Подправьте если не прав. Даже те кто работает в долине наизусть учат алгоритмы и структуры данных для собесов, а потом все как один говорят, что это можно забывать до следующего поиска работы
Просто это копирование ЗАПАДНОГО подхода к набору персонала в КРУПНЫЕ компании (Google, Amazon, Facebook и т.д.):
важно чтобы КАНДИДАТ был достаточно эрудирован (уже встречал подобные задачи и мог быстро решить предложенную)
или был сообразителен и мог быстро предложить алгоритм шенеия и оценить его плюсы и минусы.
Если работа заключается в написании рест ручек - то смысла нет.
Когда чел шарит в алгоритмах, он не будет решать реальные задачи не оптимально. Я на практике у людей, не умеющих решать алгоритмические задачи часто вижу код с неоправданно завышенной асимптотикой. Негативных следствий из этого много разных. Например, какие-то запросы серверу могут долго обрабатываться. Может потребоваться сильно больше серверов или более дорогих серверов для обеспечения работы такого решения, чем для обеспечения работы оптимального решения. Это такая тренировка специалиста с запасом. Такой подход в любой сфере жизни можно увидеть. Тяжело в учении -- легко не работе.