Асимптотически там везде K^n для n шагов. К зависит от того, как выбирать дерево. Чем больше промежуточных шагов, тем больше K. Все они экспоненциальны, но асимптотически различимы.
Да и не только в этих департаментах "разрабатывающих новые технологии". И не только в гугле/яндексе. Прям олимпиадные задачи встречаются много где. Гораздо чаще, чем люди думают. Ошибочная оценка возникает потому, что такие задачи большинством просто не распознаются алгоритмическими вообще.
Вон, те же задачи на литкоде очень часто в виде "сделайте вот это". И можно тупо перевести с человеческого на язык программирования не очень задействуя мозг довольно часто.
У программистов обычно задача - запилить фичу, исправить баг. Они в голове состоявляют план "вот надо сделать вот так и так" и делают наивное медленное тупое решение, или вообще думают "а не, так не получится сделать, давайте поменяем фичу". Перед ними не стоит алгоритмической задачи, они ее придумывают уже как решение и даже не задумываются, что тут, оказывается, надо еще что-то решать и можно эти ваши алгоритмы использовать.
Вот тут не соглашусь. Олимпиады - это не собраться раз в несколько месяцев на 5 часов, порешать задачи и все. Это надо месяцами учить разные темы. Это надо тренироваться - решать задачи почти каждый день. Это концентрация на одной теме месяцами а то и годами.
Судя по всему, под ваше определение автопилота ничего проще сильного ИИ не подходит. Но это ваше, отличное от общепринятого, определение. И Тесла такое не обещает.
при этом количество обработанных узлов - в пять раз меньше
По моей интуиции и формуле выше, чем дальше эволюция, тем сильнее будет выигрывать квадродерево. В стандартной "жизни" нет особо пространственных симметрий и периодов размера ни степени 2 ни степени 3, поэтому оба варианта будут сравнимо выигрывать от повторений.
Вообще, стандартный hashlife работает чуть-чуть по-другому. Там используется степень 2, а не 3. Откуда вы вообще 3 взяли?
Результат эволюции куска 2^n x 2^n через 2^(n-1) шагов однозначно определяется куском 2^(n+1) x 2^(n+1). Поэтому там сохраняются именно эти результаты: для куска 2^(n+1) сохраняется результат в центре размера 2^n через 2^(n-1) шагов При n >= 1. Т.е. самый маленький кусок, который вы считаете, это 4x4 через один шаг и сохраняете внутренний квадрат 2x2.
Потом, чтобы подсчитать ответ для n>1 вы отдельно считаете 9 квадратов для n-1 окаймляющих внутренний кусок, составив из них квадрат размера 2^n + 2^(n-2) через 2^(n-2) шага, потом через 4 квадрата для n-1 вы получаете ответ для внутреннего квадрата еще через 2^(n-2) шагов.
Вроде как на этих картинках цветные квадраты отмечены:
9 квадратов 4x4. Их центральные 2x2 блоки составляют квадрат 6x6
4 квадрата 4x4. Их внутренние 2x2 блоки составляют квадрат 4x4
Как у вас, надо будет всех внуков корня квадро-дерева выписать в квадрат 4x4, из них собирать куски 2x2. Потом результаты записать в матрицу 3x3, там опять составить блоки 2x2, результат даст блок 2x2 который надо взять в ответ, составив из них квадро-дерево.
Это сильно эффективнее вашего варианта со сторонами из степени 3. Тут надо всего 13=9+4 рекурсивных шагов, а не 83=49+25+9. Плюс нужно 2 последовательных шага эволюций, а не 3 как у вас, так что если параллелить, то там меньше зависимостей по вычислениям.
С другой стороны, тут экспоненциальный рост идет с основанием 2, а не 3, так что высота рекурсивного дерева для заданного количества шагов будет выше в log_2(3) раз. Но каждая вершина будет в 6 раз менее ветвиста. Так что в целом количество возможных вершин гораздо меньше, ибо 13^log_2(3) = 58.28.. < 83.
Во-первых, ну нет на практике нигде сети, где у вас сразу возникает n потоков и больше ничего, и все они существуют строго одно и то же время. Каждый поток возникает независимо от остальных, в произвольное время. У вас никогда нет задачи искать вот так n потоков. У вас есть уже как-то загруженная сеть и вы строите один маршрут для конкретного соединения. Возможно оставляя обходные пути на случай, если возникнет какой-то другой запрос.
Во-вторых, у вас тут централизованный control plane. Какой-то Software Defined Networking. Это возможно только в очень отдельных случаях. У вас какой-то свой датацентр и вы внутри что хотите то и городите. Но там практически нет задач выделить поток определенной пропускной способности. Обычно вам или надо передать данные как можно быстрее, или не так важно как передавать и тут работают приоритеты и сходимость скорости за счет какого-нибудь отката вроде как в TCP. И очереди не растут гиперболически, ибо достаточно дропать пакеты и отправитель снижает свои аппетиты сам.
Ну и пуассоновские допущения об интенсивности потоков тоже очень теоретические.
Я всего лишь говорил о том, что в бизнесовой разработке много такого, чего нет в олимпиадной.
Согласен. Но я почему-то воспринял ваш комментарий и аналогии скорее как "олимпиадные навыки противоречат бизнесу. Ну в крайнем случае вообще перпендикулярны". Ибо спринтер - плохой марафонец с большой вероятностью и как быстро он бегает стометровку никак ему не поможет на дистанциях в 40 км.
Возможно мы тут вообще друг другу одну и ту же позицию доказываем.
Хм... тогда объясните мне, почему в статье "...Tesla .. автопилот" вы обсуждаете content id, хотя это задача совсем другая?
это строго и сильно ограниченная система со строжайшими же предписаниями; иначе говоря, это – не автопилот в нормальном понимании, ибо автопилот в нормальном понимании – это замена человека-водителя
В смысле?! Такси без водителя приезжает по адресу, отвозит куда хотите. Само. Там даже на месте водителя никто не сидит.
Голые спекуляции про Content id. Это совсем другая задача, совсем не похожая на автопилот. Главная проблема там, что надо сравнивать все видео со всеми. Автопилоту лишь надо искать препятствия да категорезировать их в несколько простых классов.
если бы у Google была экономически эффективная, работающая система Content ID, не вывел ли бы он сей продукт работы с видео на рынок?
Зачем? Кому еще он нужен? У кого еще куча пользовательского контента, который надо сравнивать? Только у конкурентов ютуба разве. Нафига им давать свое конкуретное приемущество? Делать из него поиск по видео для пользователей? Слишком ресурсоемкий процесс, чтобы давать его пользователям, а пользы почти не несет. Поиск по картинкам уже неплохо работает и закрывает почти все требования. Если у пользователя есть видео клип, и он хочет найти, откуда он - можно просто сделать скриншот и в 99% оно найдется.
Оно точно очень дорого обходится гуглу и если бы не правоторговцы и абсолютно перекошенные и безумные законы о копирайте, никому бы никогда в голову не пришло такое реализовывать. У этого нет никакого экономически оправданного применения.
Примерно такой же уровень экспертизы дальше.
Что касается автопилота, у теслы свои проблемы и маск любит потуфтеть, но тот же Waymo от гугла отлично ездит на полном автопилоте во многих штатах уже несколько лет.
Хорошо, практическое применение элементарной формулы. У вас есть датчик, и вы переводите сигнал в измерение по линейной зависимости. Ах да, вы еще коэффициенты не просто считатете, а сохраняете в аж регистр. Это сложный материал?
10 задач на 5 часов - это короткие задачи. А в бизнесе часто приходится решать задачи длинные, от недели и до месяца
Но на соревнованиях обычно задачи сложные и их надо уметь разбивать на части и планировать решение. С этим навыком и длинные задачи отлично разбиваются на маленькие и уже без разницы, проект на 3 года или на месяц.
Совершенно иной объем кода, сущностей и взаимосвязей между ними, которые нужно удержать в голове.
Почему вы думаете, что человек, который может удержать в голове десятки структур данных, математических моделей и алгоритмов нужных для решения задач, не сможет удержать в голове "сущности и взаимосвязи между ними". Это один и тот же отлично развиваемый олимпиадами навык.
как родственны спринт и марафон.
Это ложная аналогия. Так получилось, что человеческому телу для взрывной скорости и экстремально длительной интенсивной работы нужны разные настройки. Именно для экстремально длительной интенсивной работы, а не просто для длительной. Ходить весь день по городу даже посредственный спринтер сможет гораздо легче среднестатистического человека, ибо он в форме. И работа в индустрии - не марафон (если у вас не пермаментный кранч с 16-часовыми рабочими днями). Это длительная но вовсе не сверх-интенсивная мыслительная работа.
Так что аналогия тут скорее, надо пешим курьером весь день разносить письма по городу. Иногда придется убегать от собак. Спринтеры тут - идеальные кандидаты.
И вообще, совершенно не очевидно, что точно так же мозгу для длительного медленного думания над бизнес задачей и интенсивным думанием в течении 5 часов над 10ю задачами, нужны какие-то разные навыки. 5-ти часовые контесты почти не отличаются от 8-ми часового рабочего дня, только в бизнесе можно пойти кофе попить, пообедать и расслабиться немного. Прямо халява какая-то. Память олимпиады развивают отлично. Способность удерживать кучу критериев и условий в голове - тоже. Иные задачи просто прочитать и осознать сложнее чем некоторые целые проекты в бизнесе. Ах да, еще внимание к деталям и вообще способность прочитать технический текст.
Если вы про то, что "решил задачу - выгрузил все про нее из памяти" на контесте, то в бизнесе все примерно так же. Вы когда какую-то фичу пишите, вы не держите в голове все про фичу, которую вы писали 2 месяца назад. Вы все время решаете одну маленькую задачу: разбить проект на подзадачи, написать вот эту фичу, исправить вон тот баг. В контекст свой вы не "загружаете" весь большой проект, а лишь маленькую релевантную часть. Что-то про другие части вы по мере надомности вспомните, но так же и на олимпиадах надо постоянно вспоминать что-то про подводные камни в подобных задачах.
ну, так-то участник как офлайн так и онлайн соревнований. в одной региональной даже в своё время даже второе место занял.
Видимо, только в школе? И на сборы вы никакие не ездили? Или вы, даже участвуя в коммандных соревнованиях, решили, что они никак не помогают работать в комманде?
в С++ 26 simd появился в стандартной библиотеке и если этот язык будет разрешен в конкретных контестах, то по каким религиозным соображением это стоит запрещать?
Да хотябы чтобы не париться с выставленем таймлимита. Ибо цель контеста проверять алгоритмы а не микрооптимизации под конкретную архитектуру. И чтобы все было более менее честно для других языков, ведь если какое-нибудь медленное O(n^2) c simd оптимизациями в C++ пройдет, а на Java сможет только O(n log n), то это будет не честно.
Оно и asm уже более менее забанено во многих местах:
Certain C++ features are not allowed: SSE intrinsics, inline assembly, clock(), changing compiler settings (using pragmas, attributes). Detection of this features is best effort and will trigger manual grading.
Далее:
Ну так на нём свет клином не сошёлся. CodeForces и LeetCode проводят постоянные периодические контесты
Тем не менее, если заниматья этим серьезно, то придется разбираться в чужом коде, читать разборы и общатся с людьми. Нет, могут быть отдельные саванты, которым просто от природы все знания уже даны, но эти исключения мы рассматривать особо не будем.
Если человек никогда не участвовал в командных тренировках, то откуда браться навыку коммуницирования? Многие могут решать задачи только методом проб и ошибок, а не каким-то глубоким планированием, большинство не способны держать в голове всю цепочку взаимосвязей
Отличная иллюстрация, почему успешная олимпиадная карьера практически гарантирует, что у человека будут основные необходимые навыки, чтобы быть отличным программистом. Потому что там "методом проб и ошибок", "не каким-то глубоким планированием" многого не добъешься.
кто-то просто с социальной тревожностью и попытки начать объяснять загоняют их в паническую петлю из-за страха сказать что-нибудь "не то"
По моему опыту даже последние интроверты и откровенные аутисты как раз с радостью говорят о том, что им интересно. И вот спортивным программированием обычно занимаются те, кому это интересно. И о коде и задачах эти "загоняемые в паническую петлю" могут разговаривать бесконечно без страха "сказать что-нибудь не то". Это же не обсуждение романтических отношений в офисе, а математика, где нельзя, даже перепутав знак или ошибившись в арифметике, нарушить какой-то этикет.
Спортивное программирование в этом плане ортогонально конретно этой проблеме с коммуницированием.
На высоком уровне и во многих популярных соревнованиях требуются навыки коммуникации. Давайте сойдемся на том, что это не гарант идеальных командных навыков для всех, кто хоть раз в жизни к этому прикоснулся, но командная работа там не такое уж и исключение.
А теперь делаем следующую часть этого трюка: будем описывать всё с точки зрения наблюдателя, опускающегося вместе с блоком.
А разве так можно? Эта система отсчета движется с ускорением. Слабо помню физику, но она точно не эквивалентна покоящейся системе отсчета. Тут, видимо просто трюк и упрощение объяснения. На самом деле те же силы можно найти в неподвижной системе счисления? Или в такой системе все еще можно считать силы и жопа там начинается только при релятивизме?
Сразу видно, человек с олимпиадным програмимрованием не знаком.
с использованием нечитаемых техник вместо вызова каких-нибудь simd интрисиков,
На олимпиадах их обычно нельзя использовать. Самый адский хак - это битовая магия какая-нибудь. И даже если ее потом использовать в индустриальном коде, ее запросто можно написать очень даже читаемой.
Ну и командная работа в спортивном программировании - это скорее исключение.
Самое пристижное и популярное соревнование - ICPC - командное. Трем людям дается один компьютер и они должны: разделять задачи, объяснять свое решение, писать его так, чтобы двое других поняли.
Даже без этого в олимпиадной среде надо уметь объяснять свое решение и понимать чужие. Потому что огромный пласт знаний передается живыми людьми друг-другу. Это очень ценный навык для коммандной работы.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу - единственное, на что они способны, это молча написать код.
Спортивное программирование действительно прививает определенный стиль кода, в основном выраженный в коротких непонятных называниях переменных. Потому что надо побыстрее решить задачу и потом этот код никто уже никогда поддерживать не будет.
Но от этой привычки можно избавиться буквально за пару недель при наличии код-ревью в процессе разработки.
Еще добавлю, что оно дает математическую базу и алгоритмическое мышление, которые потом отлично помогают с индустриальной работой. То самое умение формализовать задачу, выстроить решение и доказать его хотя бы самому себе. И когда вам встретится "олимпиадная" задача, вы ее вообще распознаете и сможете решить или хотя бы понять как искать решение.
Асимптотически там везде K^n для n шагов. К зависит от того, как выбирать дерево. Чем больше промежуточных шагов, тем больше K. Все они экспоненциальны, но асимптотически различимы.
Да и не только в этих департаментах "разрабатывающих новые технологии". И не только в гугле/яндексе. Прям олимпиадные задачи встречаются много где. Гораздо чаще, чем люди думают. Ошибочная оценка возникает потому, что такие задачи большинством просто не распознаются алгоритмическими вообще.
Вон, те же задачи на литкоде очень часто в виде "сделайте вот это". И можно тупо перевести с человеческого на язык программирования не очень задействуя мозг довольно часто.
У программистов обычно задача - запилить фичу, исправить баг. Они в голове состоявляют план "вот надо сделать вот так и так" и делают наивное медленное тупое решение, или вообще думают "а не, так не получится сделать, давайте поменяем фичу". Перед ними не стоит алгоритмической задачи, они ее придумывают уже как решение и даже не задумываются, что тут, оказывается, надо еще что-то решать и можно эти ваши алгоритмы использовать.
Вот тут не соглашусь. Олимпиады - это не собраться раз в несколько месяцев на 5 часов, порешать задачи и все. Это надо месяцами учить разные темы. Это надо тренироваться - решать задачи почти каждый день. Это концентрация на одной теме месяцами а то и годами.
Судя по всему, под ваше определение автопилота ничего проще сильного ИИ не подходит. Но это ваше, отличное от общепринятого, определение. И Тесла такое не обещает.
Быстро вы сделали, мое уважение.
По моей интуиции и формуле выше, чем дальше эволюция, тем сильнее будет выигрывать квадродерево. В стандартной "жизни" нет особо пространственных симметрий и периодов размера ни степени 2 ни степени 3, поэтому оба варианта будут сравнимо выигрывать от повторений.
В целом согласен. С листом особенно просто получается.
Вообще, стандартный hashlife работает чуть-чуть по-другому. Там используется степень 2, а не 3. Откуда вы вообще 3 взяли?
Результат эволюции куска 2^n x 2^n через 2^(n-1) шагов однозначно определяется куском 2^(n+1) x 2^(n+1). Поэтому там сохраняются именно эти результаты: для куска 2^(n+1) сохраняется результат в центре размера 2^n через 2^(n-1) шагов При n >= 1. Т.е. самый маленький кусок, который вы считаете, это 4x4 через один шаг и сохраняете внутренний квадрат 2x2.
Потом, чтобы подсчитать ответ для n>1 вы отдельно считаете 9 квадратов для n-1 окаймляющих внутренний кусок, составив из них квадрат размера 2^n + 2^(n-2) через 2^(n-2) шага, потом через 4 квадрата для n-1 вы получаете ответ для внутреннего квадрата еще через 2^(n-2) шагов.
Вроде как на этих картинках цветные квадраты отмечены:
Как у вас, надо будет всех внуков корня квадро-дерева выписать в квадрат 4x4, из них собирать куски 2x2. Потом результаты записать в матрицу 3x3, там опять составить блоки 2x2, результат даст блок 2x2 который надо взять в ответ, составив из них квадро-дерево.
Это сильно эффективнее вашего варианта со сторонами из степени 3. Тут надо всего 13=9+4 рекурсивных шагов, а не 83=49+25+9. Плюс нужно 2 последовательных шага эволюций, а не 3 как у вас, так что если параллелить, то там меньше зависимостей по вычислениям.
С другой стороны, тут экспоненциальный рост идет с основанием 2, а не 3, так что высота рекурсивного дерева для заданного количества шагов будет выше в log_2(3) раз. Но каждая вершина будет в 6 раз менее ветвиста. Так что в целом количество возможных вершин гораздо меньше, ибо 13^log_2(3) = 58.28.. < 83.
Все-таки это очень теоретическая работа.
Во-первых, ну нет на практике нигде сети, где у вас сразу возникает n потоков и больше ничего, и все они существуют строго одно и то же время. Каждый поток возникает независимо от остальных, в произвольное время. У вас никогда нет задачи искать вот так n потоков. У вас есть уже как-то загруженная сеть и вы строите один маршрут для конкретного соединения. Возможно оставляя обходные пути на случай, если возникнет какой-то другой запрос.
Во-вторых, у вас тут централизованный control plane. Какой-то Software Defined Networking. Это возможно только в очень отдельных случаях. У вас какой-то свой датацентр и вы внутри что хотите то и городите. Но там практически нет задач выделить поток определенной пропускной способности. Обычно вам или надо передать данные как можно быстрее, или не так важно как передавать и тут работают приоритеты и сходимость скорости за счет какого-нибудь отката вроде как в TCP. И очереди не растут гиперболически, ибо достаточно дропать пакеты и отправитель снижает свои аппетиты сам.
Ну и пуассоновские допущения об интенсивности потоков тоже очень теоретические.
Согласен. Но я почему-то воспринял ваш комментарий и аналогии скорее как "олимпиадные навыки противоречат бизнесу. Ну в крайнем случае вообще перпендикулярны". Ибо спринтер - плохой марафонец с большой вероятностью и как быстро он бегает стометровку никак ему не поможет на дистанциях в 40 км.
Возможно мы тут вообще друг другу одну и ту же позицию доказываем.
Хм... тогда объясните мне, почему в статье "...Tesla .. автопилот" вы обсуждаете content id, хотя это задача совсем другая?
В смысле?! Такси без водителя приезжает по адресу, отвозит куда хотите. Само. Там даже на месте водителя никто не сидит.
Голые спекуляции про Content id. Это совсем другая задача, совсем не похожая на автопилот. Главная проблема там, что надо сравнивать все видео со всеми. Автопилоту лишь надо искать препятствия да категорезировать их в несколько простых классов.
Зачем? Кому еще он нужен? У кого еще куча пользовательского контента, который надо сравнивать? Только у конкурентов ютуба разве. Нафига им давать свое конкуретное приемущество? Делать из него поиск по видео для пользователей? Слишком ресурсоемкий процесс, чтобы давать его пользователям, а пользы почти не несет. Поиск по картинкам уже неплохо работает и закрывает почти все требования. Если у пользователя есть видео клип, и он хочет найти, откуда он - можно просто сделать скриншот и в 99% оно найдется.
Оно точно очень дорого обходится гуглу и если бы не правоторговцы и абсолютно перекошенные и безумные законы о копирайте, никому бы никогда в голову не пришло такое реализовывать. У этого нет никакого экономически оправданного применения.
Примерно такой же уровень экспертизы дальше.
Что касается автопилота, у теслы свои проблемы и маск любит потуфтеть, но тот же Waymo от гугла отлично ездит на полном автопилоте во многих штатах уже несколько лет.
Хорошо, практическое применение элементарной формулы. У вас есть датчик, и вы переводите сигнал в измерение по линейной зависимости. Ах да, вы еще коэффициенты не просто считатете, а сохраняете в аж регистр. Это сложный материал?
Но на соревнованиях обычно задачи сложные и их надо уметь разбивать на части и планировать решение. С этим навыком и длинные задачи отлично разбиваются на маленькие и уже без разницы, проект на 3 года или на месяц.
Почему вы думаете, что человек, который может удержать в голове десятки структур данных, математических моделей и алгоритмов нужных для решения задач, не сможет удержать в голове "сущности и взаимосвязи между ними". Это один и тот же отлично развиваемый олимпиадами навык.
Это ложная аналогия. Так получилось, что человеческому телу для взрывной скорости и экстремально длительной интенсивной работы нужны разные настройки. Именно для экстремально длительной интенсивной работы, а не просто для длительной. Ходить весь день по городу даже посредственный спринтер сможет гораздо легче среднестатистического человека, ибо он в форме. И работа в индустрии - не марафон (если у вас не пермаментный кранч с 16-часовыми рабочими днями). Это длительная но вовсе не сверх-интенсивная мыслительная работа.
Так что аналогия тут скорее, надо пешим курьером весь день разносить письма по городу. Иногда придется убегать от собак. Спринтеры тут - идеальные кандидаты.
И вообще, совершенно не очевидно, что точно так же мозгу для длительного медленного думания над бизнес задачей и интенсивным думанием в течении 5 часов над 10ю задачами, нужны какие-то разные навыки. 5-ти часовые контесты почти не отличаются от 8-ми часового рабочего дня, только в бизнесе можно пойти кофе попить, пообедать и расслабиться немного. Прямо халява какая-то. Память олимпиады развивают отлично. Способность удерживать кучу критериев и условий в голове - тоже. Иные задачи просто прочитать и осознать сложнее чем некоторые целые проекты в бизнесе. Ах да, еще внимание к деталям и вообще способность прочитать технический текст.
Если вы про то, что "решил задачу - выгрузил все про нее из памяти" на контесте, то в бизнесе все примерно так же. Вы когда какую-то фичу пишите, вы не держите в голове все про фичу, которую вы писали 2 месяца назад. Вы все время решаете одну маленькую задачу: разбить проект на подзадачи, написать вот эту фичу, исправить вон тот баг. В контекст свой вы не "загружаете" весь большой проект, а лишь маленькую релевантную часть. Что-то про другие части вы по мере надомности вспомните, но так же и на олимпиадах надо постоянно вспоминать что-то про подводные камни в подобных задачах.
Видимо, только в школе? И на сборы вы никакие не ездили? Или вы, даже участвуя в коммандных соревнованиях, решили, что они никак не помогают работать в комманде?
Да хотябы чтобы не париться с выставленем таймлимита. Ибо цель контеста проверять алгоритмы а не микрооптимизации под конкретную архитектуру. И чтобы все было более менее честно для других языков, ведь если какое-нибудь медленное O(n^2) c simd оптимизациями в C++ пройдет, а на Java сможет только O(n log n), то это будет не честно.
Оно и asm уже более менее забанено во многих местах:
Далее:
Тем не менее, если заниматья этим серьезно, то придется разбираться в чужом коде, читать разборы и общатся с людьми. Нет, могут быть отдельные саванты, которым просто от природы все знания уже даны, но эти исключения мы рассматривать особо не будем.
Отличная иллюстрация, почему успешная олимпиадная карьера практически гарантирует, что у человека будут основные необходимые навыки, чтобы быть отличным программистом. Потому что там "методом проб и ошибок", "не каким-то глубоким планированием" многого не добъешься.
По моему опыту даже последние интроверты и откровенные аутисты как раз с радостью говорят о том, что им интересно. И вот спортивным программированием обычно занимаются те, кому это интересно. И о коде и задачах эти "загоняемые в паническую петлю" могут разговаривать бесконечно без страха "сказать что-нибудь не то". Это же не обсуждение романтических отношений в офисе, а математика, где нельзя, даже перепутав знак или ошибившись в арифметике, нарушить какой-то этикет.
На высоком уровне и во многих популярных соревнованиях требуются навыки коммуникации. Давайте сойдемся на том, что это не гарант идеальных командных навыков для всех, кто хоть раз в жизни к этому прикоснулся, но командная работа там не такое уж и исключение.
Прочитал. Кроме секции "Как рассчитать коэффициенты линейной функции" математики там нет (если не считать формулу среднего арифметического).
А разве так можно? Эта система отсчета движется с ускорением. Слабо помню физику, но она точно не эквивалентна покоящейся системе отсчета. Тут, видимо просто трюк и упрощение объяснения. На самом деле те же силы можно найти в неподвижной системе счисления? Или в такой системе все еще можно считать силы и жопа там начинается только при релятивизме?
Метод подбора коэффициентов линейной функции по двум точкам - это теперь "сложный" материал?
А если игра какие-то ресурсы тянет с файловой системы, как это работает?
Сразу видно, человек с олимпиадным програмимрованием не знаком.
На олимпиадах их обычно нельзя использовать. Самый адский хак - это битовая магия какая-нибудь. И даже если ее потом использовать в индустриальном коде, ее запросто можно написать очень даже читаемой.
Самое пристижное и популярное соревнование - ICPC - командное. Трем людям дается один компьютер и они должны: разделять задачи, объяснять свое решение, писать его так, чтобы двое других поняли.
Даже без этого в олимпиадной среде надо уметь объяснять свое решение и понимать чужие. Потому что огромный пласт знаний передается живыми людьми друг-другу. Это очень ценный навык для коммандной работы.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу - единственное, на что они способны, это молча написать код.
Спортивное программирование действительно прививает определенный стиль кода, в основном выраженный в коротких непонятных называниях переменных. Потому что надо побыстрее решить задачу и потом этот код никто уже никогда поддерживать не будет.
Но от этой привычки можно избавиться буквально за пару недель при наличии код-ревью в процессе разработки.
Еще добавлю, что оно дает математическую базу и алгоритмическое мышление, которые потом отлично помогают с индустриальной работой. То самое умение формализовать задачу, выстроить решение и доказать его хотя бы самому себе. И когда вам встретится "олимпиадная" задача, вы ее вообще распознаете и сможете решить или хотя бы понять как искать решение.