Тут другая ситуация: студент к экзамену ничего не выучил, но списал ответ у товарища (не факт что правильно, кстати). И он начинает вам заливать. Складно, красиво, но вообще не факт что релевантно к теме экзамена. Дело в том, что эти задачки много где приводятся с кодом, но редко с вменяемым объяснением. Поэтому LLMка, даже если угадает код, редко "вспомнит" хоть какие-то факты из объяснений.
Жадно вы пойдете в 10->100 и оттуда в 1000 уже никак не попадете. Даже если вы будете идти в максимальное число по массиву, легко подобрать тест, где это не будет работать.
Если у вас есть хоть какие-то данные и работа с ними, то там постоянно именно такие "олимпиадные" задачки и возникают. У меня несколько статей об этом есть. Бесстыжая ссылка.
Вот только без знания базы и насмотренности на такие задачи вы даже и не заметите этого. Потому что почти все такие задачи можно решить наивно тупо переведя задачу с русского на язык программирования. Ну тормозит немного, что такого?
Чтобы распознать задачу и понять что вам ИИ не наврал, надо знать базу.
Да, в формошлепстве такое встречается реже. Но ИТ состоит далеко не только из формошлепства.
Придумывают новые алгоритмы инженеры, которых выкупают за миллионы топовые IT компании,
Нет. Если у вас стоит задача посчитать какую-то метрику, то вы должны придумать эффективный алгоритм рассчета этой метрики, или свести задачу к известному алгоритму. Вы не будете на каждый чих дергать топового инженера за миллионы.
Например, если вам надо посчитать среднее в радиусе вокруг каждого числа в массиве, то вы сами должны догадаться, что вам надо просто поддерживать сумму в окне, а не гнать 2 вложенных цикла. Нет никакой библиотеки, которая бы такие вещи делала. Потому что это слишком простая вещь. Как и нет библиотеки, которая бы решала задачу из статьи, потому что это слишком специфичная задача. И большинство задач, сотящих перед вами, будут именно такими - уникальными или слишком простыми, чтобы быть в библиотеке.
Вообще, реализацию найти можно, но вам надо знать ключевые слова "среднее в окне", "динамическое программирование" и все такое.
Вы так говорите, будто задачи с литкода в практике не встречаются. Встречаются только так. Вот бесстыжая ссылка на мою статью. Только без знаний базы и прорешивания кучи таких задач вы даже и не заметите, что вот это вот тривиальное действо из двух вложенных циклов на самом деле какой-то алгоритм. Поэтому бытует ошибочное мнение, что это не практичные задачи.
Вот объяснения LLM делать вообще почти не умеет. Она почти гарантировано галлюционирует их. Весьма правдоподобные, но противоречивые, ложные и нелогичные.
Кстати возможно так и стоит поступить - решить обратную задачу (кратчайший путь), только брать веса с противоположным знаком.
Плохая идея. Большинство алгоритмов поиска кратчайшего пути, вроде Дейкстры, вообще не работают, если в графе есть отрицательные ребра. Даже если нет отрицательных циклов. Работает какой-нибудь алгоритм Беллмана-Форда работает, но он в N раз медленнее на этой задаче.
Надо знать какие бывают алгоритмы, и где они применимы. Соответственно, ваш граф ациклический - так что тут работает динамическое программирование и никакие другие алгоритмы тут не нужны. Они сложнее, медленнее, и не факт, что заработают вообще из-за отрицательных ребер. А динамическому программированию вообще пофигу, что считать - минимальную длину, максимальную длину, произведение, минимальное или максимальное ребро на пути.
Задача по поиску кратчайшего пути между двумя точками графа общеизвестная и за много лет оптимизирована, а задача самого длинного пути решается аналогичным образом
Ха. Задача поиска самого длинного пути - на порядки сложнее, если только у вас граф не ацикличиский, где почти любая аддитивная целевая функция пути решается одним и тем же алгоритмом динамического программирования (что и есть случай в статье).
Это потому, что критерий кратчайшего пути почти автоматически исключает хождение по циклам, это же не выгодно. А вот в длиннейшем пути ходить по циклам бывает выгодно.
Это стандартная задача на динамическое программирование. Тут можно как снизу-вверх, так и сверху-вниз делать. Хоть циклами, хоть рекурсией с запоминанием результатов.
Да, кстати, у вас практика работы с олимпиадниками есть, скажите, а они у вас все выгорают до 23 лет и уходят из профессии, как утверждает @marteinветкой выше?
Опять же, ни одного упоминания олимпиадников нет. Вы сову на глобус натягиваете.
Это обычная стандартная ситуация не думания о будущем. Если не думать о техдолге постоянно, любая компания скатывается в это, даже если там нет ни одного олимпиадника.
А моя практика показывает обратное. В гугле олимпиадников довольно много (их особо активно доставали рекрутеры гугла, гугл проводил собственные соревнования вроде code jam, да и олимпиадникам интервью очень просты). Сам ревьювил много кода от них, и олимпиадного не поддерживаемого кода вообще ни разу не встречал. Люди еще до того как отправить первый код читали руководство по стилю и все понимали.
И есть много компаний где доля олимпиадников очень влика и как-то они от технического долга и ЧСВ сотрудников не развалились. Вон, пока вконтакт не отжали, там почти все олимпиадниками писалось. Брат Павла Дурова - Николай - чемпион мира вообще, они из олимпиадной тусовки кучу народу набрали с самого начала. И была самая быстрая и удобная соцсеть.
citation needed, как говорится. Не знаю ни одного олимпиадника, выгоревшего в 23 лет: все мои знакомые а так же знаментые личности продолжают работать, никто не выгорел. Нельзя заниматься этими соревнованиями, если вам не нравиться кодить. Эти люди любят программирование и не уйдут из профессии.
Если соревнование на время, то это противоречит читаемому индустриальному коду. Это был бы другой класс соревнований, что-то вроде код-гольфа, только наоборот - оценивается не как быстро решили задачу, а какой красивый код написали. Но тут нет никаких формальных критериев, красота кода или его читабильность субъективны, поэтому такие соревнования практически невозможны.
Имейте ввиду, что эти олимпиадники они пишут не просто "непонятный" код, а короткий, понятный в команде код. Там свой стиль и свои соглашения. Это не отсутствие стиля и подхода, а свой особый подход. Так что, при наличии код ревью, олимпиадников можно переучить на другой стиль за пару недель.
А то как бы не получилось что нанимаем программистов за $100 в час чтобы они сэкономили $1 в час.
Вы как-то не так считаете. Программист потратил час-два-три, и потом этот $1 в час экономится каждый час, каждый день. Через 4-12 дней оно выйдет в ноль и потом начнет приносить прибыль.
И вообще, какие инновации, какое внедрение? Это фикс уже работающего в проде кода, чтобы он работал лучше. Вы перед каждым изменением в коде просчитываете все экономические последствия? А вы просчитываете, насколько экономически целесообразен этот просчет, ведь программист за $100 в час вместо полезной работы сидит считает, надо ли фиксить код, или итак сойдет. А имеет ли тогда смысл просчитывать целесообразность просчета целесообразности подсчета? Вашу логику за пол шажочка можно свести к абсурду.
Просчитывать надо большие проекты при планировании работы за большие промежутки вермени. А фиксить баги и проблемы в коде - это прямая рабочая обязанность программиста, за это ему и платят.
Формализуйте немного ваш алгоритм, увидите тот же самый квадрат. Вы там "для каждого пользователя из множества" что-то выставляете, это и будет квадрат. Если это вообще работает.
Тут другая ситуация: студент к экзамену ничего не выучил, но списал ответ у товарища (не факт что правильно, кстати). И он начинает вам заливать. Складно, красиво, но вообще не факт что релевантно к теме экзамена. Дело в том, что эти задачки много где приводятся с кодом, но редко с вменяемым объяснением. Поэтому LLMка, даже если угадает код, редко "вспомнит" хоть какие-то факты из объяснений.
Люди, вы всерьез этот выхлоп нейронки обсуждаете? Вам делать нечего?
Гугл вкладывает с прибыли, опенаи - берет в долг у инвесторов. Риски гугла тут принципиально ничем не отличаются от других направлений.
Жадность тут не работает.
Жадно вы пойдете в 10->100 и оттуда в 1000 уже никак не попадете. Даже если вы будете идти в максимальное число по массиву, легко подобрать тест, где это не будет работать.
Если у вас есть хоть какие-то данные и работа с ними, то там постоянно именно такие "олимпиадные" задачки и возникают. У меня несколько статей об этом есть. Бесстыжая ссылка.
Вот только без знания базы и насмотренности на такие задачи вы даже и не заметите этого. Потому что почти все такие задачи можно решить наивно тупо переведя задачу с русского на язык программирования. Ну тормозит немного, что такого?
Чтобы распознать задачу и понять что вам ИИ не наврал, надо знать базу.
Да, в формошлепстве такое встречается реже. Но ИТ состоит далеко не только из формошлепства.
Вы что-то напутали, там алгоритм за O(N^2) в итоге. Никаких 2^100 нигде нет.
Нет. Если у вас стоит задача посчитать какую-то метрику, то вы должны придумать эффективный алгоритм рассчета этой метрики, или свести задачу к известному алгоритму. Вы не будете на каждый чих дергать топового инженера за миллионы.
Например, если вам надо посчитать среднее в радиусе вокруг каждого числа в массиве, то вы сами должны догадаться, что вам надо просто поддерживать сумму в окне, а не гнать 2 вложенных цикла. Нет никакой библиотеки, которая бы такие вещи делала. Потому что это слишком простая вещь. Как и нет библиотеки, которая бы решала задачу из статьи, потому что это слишком специфичная задача. И большинство задач, сотящих перед вами, будут именно такими - уникальными или слишком простыми, чтобы быть в библиотеке.
Вообще, реализацию найти можно, но вам надо знать ключевые слова "среднее в окне", "динамическое программирование" и все такое.
Вы так говорите, будто задачи с литкода в практике не встречаются. Встречаются только так. Вот бесстыжая ссылка на мою статью. Только без знаний базы и прорешивания кучи таких задач вы даже и не заметите, что вот это вот тривиальное действо из двух вложенных циклов на самом деле какой-то алгоритм. Поэтому бытует ошибочное мнение, что это не практичные задачи.
Вот объяснения LLM делать вообще почти не умеет. Она почти гарантировано галлюционирует их. Весьма правдоподобные, но противоречивые, ложные и нелогичные.
Плохая идея. Большинство алгоритмов поиска кратчайшего пути, вроде Дейкстры, вообще не работают, если в графе есть отрицательные ребра. Даже если нет отрицательных циклов. Работает какой-нибудь алгоритм Беллмана-Форда работает, но он в N раз медленнее на этой задаче.
Надо знать какие бывают алгоритмы, и где они применимы. Соответственно, ваш граф ациклический - так что тут работает динамическое программирование и никакие другие алгоритмы тут не нужны. Они сложнее, медленнее, и не факт, что заработают вообще из-за отрицательных ребер. А динамическому программированию вообще пофигу, что считать - минимальную длину, максимальную длину, произведение, минимальное или максимальное ребро на пути.
Ха. Задача поиска самого длинного пути - на порядки сложнее, если только у вас граф не ацикличиский, где почти любая аддитивная целевая функция пути решается одним и тем же алгоритмом динамического программирования (что и есть случай в статье).
Это потому, что критерий кратчайшего пути почти автоматически исключает хождение по циклам, это же не выгодно. А вот в длиннейшем пути ходить по циклам бывает выгодно.
Это стандартная задача на динамическое программирование. Тут можно как снизу-вверх, так и сверху-вниз делать. Хоть циклами, хоть рекурсией с запоминанием результатов.
Да, кстати, у вас практика работы с олимпиадниками есть, скажите, а они у вас все выгорают до 23 лет и уходят из профессии, как утверждает @marteinветкой выше?
Опять же, ни одного упоминания олимпиадников нет. Вы сову на глобус натягиваете.
Это обычная стандартная ситуация не думания о будущем. Если не думать о техдолге постоянно, любая компания скатывается в это, даже если там нет ни одного олимпиадника.
Нагуглил вот это: https://darkcoding.net/software/facebooks-code-quality-problem/
Там нигде не упоминается ни "competitive", ни "olympiad". Ни одного упоминания олимпиадного программирования или соревнований.
А моя практика показывает обратное. В гугле олимпиадников довольно много (их особо активно доставали рекрутеры гугла, гугл проводил собственные соревнования вроде code jam, да и олимпиадникам интервью очень просты). Сам ревьювил много кода от них, и олимпиадного не поддерживаемого кода вообще ни разу не встречал. Люди еще до того как отправить первый код читали руководство по стилю и все понимали.
И есть много компаний где доля олимпиадников очень влика и как-то они от технического долга и ЧСВ сотрудников не развалились. Вон, пока вконтакт не отжали, там почти все олимпиадниками писалось. Брат Павла Дурова - Николай - чемпион мира вообще, они из олимпиадной тусовки кучу народу набрали с самого начала. И была самая быстрая и удобная соцсеть.
citation needed, как говорится. Не знаю ни одного олимпиадника, выгоревшего в 23 лет: все мои знакомые а так же знаментые личности продолжают работать, никто не выгорел. Нельзя заниматься этими соревнованиями, если вам не нравиться кодить. Эти люди любят программирование и не уйдут из профессии.
Если соревнование на время, то это противоречит читаемому индустриальному коду. Это был бы другой класс соревнований, что-то вроде код-гольфа, только наоборот - оценивается не как быстро решили задачу, а какой красивый код написали. Но тут нет никаких формальных критериев, красота кода или его читабильность субъективны, поэтому такие соревнования практически невозможны.
Имейте ввиду, что эти олимпиадники они пишут не просто "непонятный" код, а короткий, понятный в команде код. Там свой стиль и свои соглашения. Это не отсутствие стиля и подхода, а свой особый подход. Так что, при наличии код ревью, олимпиадников можно переучить на другой стиль за пару недель.
Вы как-то не так считаете. Программист потратил час-два-три, и потом этот $1 в час экономится каждый час, каждый день. Через 4-12 дней оно выйдет в ноль и потом начнет приносить прибыль.
И вообще, какие инновации, какое внедрение? Это фикс уже работающего в проде кода, чтобы он работал лучше. Вы перед каждым изменением в коде просчитываете все экономические последствия? А вы просчитываете, насколько экономически целесообразен этот просчет, ведь программист за $100 в час вместо полезной работы сидит считает, надо ли фиксить код, или итак сойдет. А имеет ли тогда смысл просчитывать целесообразность просчета целесообразности подсчета? Вашу логику за пол шажочка можно свести к абсурду.
Просчитывать надо большие проекты при планировании работы за большие промежутки вермени. А фиксить баги и проблемы в коде - это прямая рабочая обязанность программиста, за это ему и платят.
Формализуйте немного ваш алгоритм, увидите тот же самый квадрат. Вы там "для каждого пользователя из множества" что-то выставляете, это и будет квадрат. Если это вообще работает.