Голые спекуляции про 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 - командное. Трем людям дается один компьютер и они должны: разделять задачи, объяснять свое решение, писать его так, чтобы двое других поняли.
Даже без этого в олимпиадной среде надо уметь объяснять свое решение и понимать чужие. Потому что огромный пласт знаний передается живыми людьми друг-другу. Это очень ценный навык для коммандной работы.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу - единственное, на что они способны, это молча написать код.
Спортивное программирование действительно прививает определенный стиль кода, в основном выраженный в коротких непонятных называниях переменных. Потому что надо побыстрее решить задачу и потом этот код никто уже никогда поддерживать не будет.
Но от этой привычки можно избавиться буквально за пару недель при наличии код-ревью в процессе разработки.
Еще добавлю, что оно дает математическую базу и алгоритмическое мышление, которые потом отлично помогают с индустриальной работой. То самое умение формализовать задачу, выстроить решение и доказать его хотя бы самому себе. И когда вам встретится "олимпиадная" задача, вы ее вообще распознаете и сможете решить или хотя бы понять как искать решение.
Проблема в том, что генерировать бред на порядки проще, чем его опровергать, но я попробую. Вот взяли вы 12 каких-то чисел. Вы могли бы точно так же написать числа от 1 до 12.
Вы потом долго расписываете как этот круг можно разбить на 2, 3, 4 и 6 кусков. Ну... да? Это потому что 12 делится на 2,3,4 и 6. При чем тут ваша модель разделения?
Свойства музыкальной шкалы и цветового круга никак не связаны с вашими числами, или вашими икосаэдрами, а их специально так составляли. Возьмем музыкальную шкалу. Соседние ноты отличаются по частоте в одинаковое количество раз (q=). Поэтому, если их брать через одну, через 2 и т.д., то получим ноты, опять же отличающиеся в одинаковое количество раз по частоте, что создает гармонию и красивое звучание. Поэтому именно такие через 1,2 и т.д. ноты и образуют аккорды. Никак с вашими числами это не связано.
Эти совпадения никак не следуют из вашей "модели", не несут какого-то особого смысла и не открвают никакую глубокую философскую истину.
Арифметическое выражение этого факта: произведение двух соседних делителей числа даёт делитель промежуточной вершины
Вот тут вы попытались как-то свою нумерологию привезать к математике... Но запутались.
У вас каждая промежуточная вершина по определению произведение двух соседних. Поэтому произведение двух соседних даст промежуточную вершиную. При чем тут ее делитель? Ну да, вы так постулировали, выписывать это как какое-то откровение - просто разувание материала для придания ему внушительного вида.
То, что все числа делители 900... Н у так вы 900 так и нашли, видимо. У любого набра чисел можно найти наименьший общий делитель. Он всегда есть.
Точно такие же "интересные" факты вы бы нашли, если бы изначально запихали числа в круг в порядке 2, 6, 3, 15, 5, 10.
Связь с икосаэдром и тетраэдром натянута. Вот у вас там в икосадре изумрудный (3^2*5) соседствует с 3, 5 и 3*5. Почему 3 получилась в квадрате, а 5 - нет? Вон, какие-то конкретные грани октаэдра дают "интересные" тройки, но тетраэдр симметричен, а остальные грани ничего интересного не дают. Хотя, если порыться, можно придумать что-то инетерсное о любом объекте, делая все ваши наблюдения субъективным поиском скрытого смысла и раздуванием значимости на пустом месте.
Вообще, вся ваша статья - это удивление каким-то симметриям цикличиской группы и поиск каких-то совпадений.
Геометрия аккордов и гармоний одна и та же; различается лишь среда — музыка разворачивается во времени, цвет — в пространстве. Общий закон: чем симметричнее фигура, тем меньше у неё привязки (якоря)
Псевдофилосовский бред. Да симметрии красивы и чем более сложная группа симметрии, тем большими способами ее можно вращать, тем больше всяких псевдоглубоких наблюдений о ней можно сделать.
Если вы его используете для поиска достижимых вершин, веса ребер вам вообще безразличны.
Видимо, вы его используете для подсчета суммарных очков в поле и получения их в порядке возрастания, т.е. это не стандартная топологическая сортировка через bfs снизу-вверх, а сортировка вершин по расстоянию от начала через обход сверзу-вниз, которая гарантирует топологический порядок. Так?
Тут никакой ошибки нет, просто оптимальный алгоритм на обычном поле действительно не будет оптимальным на "злом".
В смысле. Оптимальный на злом поле должен брать в расчет злое поле. Но в принципе, я понял. На этом стоит заострить внимание в статье, что алгоритм считает лучшую стратегию в среднем, но играет против худшего случая.
Только сейчас заметил, у вас rand-angry иногда даже лучше best-angry. Какое же оно тогда best? Что-то у вас явно не так, раз есть стратегия набирающая больше очков оптимальной.
Потому что, как я выше писал, в случае злодея надо оценивать не матожидание а тупо финальный счет. Игрок выбирает ход с максимальной оценкой, злыдень - с минимальной.
Если по дереву ходов где-то внизу расходятся рядом есть очень плохой путь и очень хороший, то игрок-то этот очень плохой никогда не выберет. Но при счите матожидания, этот плохой путь портит оценку хода в начале и ваша best стратегия выбирает средний вариант, потому что рядом с ним не было варианта сильно ошибиться.
А в случае случайных клеток, надо считать матожидание только по выбору новой клетки и никак не по движению. Игрок выбирает одно из 4 направлений минимизируя оценку. Матожидание только по случайной величине делается, ход игрока - не случаен, вы его вычисляете.
Единственный вопрос, как понять, в каком порядке обходить вершины?
Ведь каждый раз после хода игрока в случайной (или худшей) клетке появляется 2 или 4. А значит общая сумма очков на поле увеличится. Поэтому все поля топологически упорядочены по сумме очков. Тут нет циклов. Поэтому тут вообще работает динамика. Если бы были циклы, то пришлось бы решать систему линейных уравнений для поиска матожидания.
Простой способ не думать о порядке, это реализовать динамику сверху вниз, через рекурсию от начального состояния. Это просто пустое поле.
Не совсем понял, как вы тут применяете 1-2-bfs. Можно по-подробнее? Предполагаю, что это у вас топологическая сортировка снизу-вверх. Так тоже можно. Но проще же отсортировать все тупо по сумме очков. Можно даже подсчетом за линию.
Еще, если рассматривать "злобную" клетку, то у вас получается игра двух игроков - один сдвигает поле, другой кидает в пустую клетку 2 или 4. Первый максимизирует сумму, второй минимизирует. Тут уже можно рассматривать не матожидание, а минимакс: какое максимальное количество очков может себе гарантировать первый игрок.
Еще вопрос, когда вы считаете, что игра остановилась?
Проводили ли вы какую-то дедупликацию состояний, вроде поворотов/отражений? Казалось, бы если гравитационный ход заменить на поворот и всегда падение вниз, то все состояния будут сильно более похожи: всего 4^3 вариантов какие клетки вообще могут быть заполнены, в каждом столбе количество очков должно различатся у соседних клеток.
У вас нет алгоритма как такового на самом деле. У вас формулировка задачи для решателя. Да, там n^2m переменных и очень много ограничений, и их надо циклами сгенерировать, но это не очень достойно гордого названия "алгоритм".
Математическая формулировка - это тоже работа и это стоит статьи, но я бы не называл это алгоритмом.
Там где у вас формула для целевой функции L() у вас неточность в нотации. Сумма по переменной i, означающей ребро, а внутри u_ij, но вот это i внутри - это уже узел, а не ребро. Правильно было бы записать сумму по 1 <= i,j <=n, Где n - количество узлов. Но это мелочь, просто в глаза бросилось.
А вопрос по делу: как работает оптимизация, что за решатель? У вас линейные ограничения, но целевая функция не линейная и даже не квадратичная. Как должно оно работает?
Кажется, вашу задачу можно свести к задаче линейного программирования, если все потоки и ограничения сделать целыми. Вроде как пропускная способность бит/с и потоки тоже в неделимых битах/с считать. Тогда можно разбить каждое ребро с пропускной способностью C на кучу параллельных ребер с пропускными способностями 1 бит/c и назначить им цены: 0/C-1/(C-1), 2/(C-2) - 1/(C-1)... ,(C-1)/1- (C-2)/2. Фактически, цена ребра - это разность L(k)-L(k-1) - на сколько увеличится штраф по изначальному ребру, если по нему пустить дополнительную единицу потока, пока там уже было k-1 потока. Поскольку целевая функция выпуклая от полного потока по ребру, то приращения строго возрастают при увеличении потока, поэтому просто взяв k минимальных параллельных ребер вы получите точно целевую функцию при потоке k по изначальному ребру. И вот уже задача свелась к мульти-потоку в графе. Тут уже линейные решатели (при чем даже не целочисленные) все решат, возможно даже быстрее. А если поток всего один, то задача вообще за полиномиальное время решается.
С другой стороны, это сильно увеличивает количество ребер в графе. Но тут можно балансировать точность и скорость. Если считать не в бит/c а кбит/c или 100кбит/c, то вы уменьшаете количество параллельных ребер и ускоряете решение.
Гуглите в сторону выпуклых целевых функций для максимального потока в графе.
Интересная тема, но на практике не применима. Таскать конкретную LLM-ку с архиватором слишком накладно. А польза весьма небольшая. Оно сжимает только человеческий текст. Даже не plaintext данные. Те же логи оно уже будет предсказывать плохо. А человеческий текст итак неплохо сжимается классическими алгоритмами.
Голые спекуляции про Content id. Это совсем другая задача, совсем не похожая на автопилот. Главная проблема там, что надо сравнивать все видео со всеми. Автопилоту лишь надо искать препятствия да категорезировать их в несколько простых классов.
Зачем? Кому еще он нужен? У кого еще куча пользовательского контента, который надо сравнивать? Только у конкурентов ютуба разве. Нафига им давать свое конкуретное приемущество? Делать из него поиск по видео для пользователей? Слишком ресурсоемкий процесс, чтобы давать его пользователям, а пользы почти не несет. Поиск по картинкам уже неплохо работает и закрывает почти все требования. Если у пользователя есть видео клип, и он хочет найти, откуда он - можно просто сделать скриншот и в 99% оно найдется.
Оно точно очень дорого обходится гуглу и если бы не правоторговцы и абсолютно перекошенные и безумные законы о копирайте, никому бы никогда в голову не пришло такое реализовывать. У этого нет никакого экономически оправданного применения.
Примерно такой же уровень экспертизы дальше.
Что касается автопилота, у теслы свои проблемы и маск любит потуфтеть, но тот же Waymo от гугла отлично ездит на полном автопилоте во многих штатах уже несколько лет.
Хорошо, практическое применение элементарной формулы. У вас есть датчик, и вы переводите сигнал в измерение по линейной зависимости. Ах да, вы еще коэффициенты не просто считатете, а сохраняете в аж регистр. Это сложный материал?
Но на соревнованиях обычно задачи сложные и их надо уметь разбивать на части и планировать решение. С этим навыком и длинные задачи отлично разбиваются на маленькие и уже без разницы, проект на 3 года или на месяц.
Почему вы думаете, что человек, который может удержать в голове десятки структур данных, математических моделей и алгоритмов нужных для решения задач, не сможет удержать в голове "сущности и взаимосвязи между ними". Это один и тот же отлично развиваемый олимпиадами навык.
Это ложная аналогия. Так получилось, что человеческому телу для взрывной скорости и экстремально длительной интенсивной работы нужны разные настройки. Именно для экстремально длительной интенсивной работы, а не просто для длительной. Ходить весь день по городу даже посредственный спринтер сможет гораздо легче среднестатистического человека, ибо он в форме. И работа в индустрии - не марафон (если у вас не пермаментный кранч с 16-часовыми рабочими днями). Это длительная но вовсе не сверх-интенсивная мыслительная работа.
Так что аналогия тут скорее, надо пешим курьером весь день разносить письма по городу. Иногда придется убегать от собак. Спринтеры тут - идеальные кандидаты.
И вообще, совершенно не очевидно, что точно так же мозгу для длительного медленного думания над бизнес задачей и интенсивным думанием в течении 5 часов над 10ю задачами, нужны какие-то разные навыки. 5-ти часовые контесты почти не отличаются от 8-ми часового рабочего дня, только в бизнесе можно пойти кофе попить, пообедать и расслабиться немного. Прямо халява какая-то. Память олимпиады развивают отлично. Способность удерживать кучу критериев и условий в голове - тоже. Иные задачи просто прочитать и осознать сложнее чем некоторые целые проекты в бизнесе. Ах да, еще внимание к деталям и вообще способность прочитать технический текст.
Если вы про то, что "решил задачу - выгрузил все про нее из памяти" на контесте, то в бизнесе все примерно так же. Вы когда какую-то фичу пишите, вы не держите в голове все про фичу, которую вы писали 2 месяца назад. Вы все время решаете одну маленькую задачу: разбить проект на подзадачи, написать вот эту фичу, исправить вон тот баг. В контекст свой вы не "загружаете" весь большой проект, а лишь маленькую релевантную часть. Что-то про другие части вы по мере надомности вспомните, но так же и на олимпиадах надо постоянно вспоминать что-то про подводные камни в подобных задачах.
Видимо, только в школе? И на сборы вы никакие не ездили? Или вы, даже участвуя в коммандных соревнованиях, решили, что они никак не помогают работать в комманде?
Да хотябы чтобы не париться с выставленем таймлимита. Ибо цель контеста проверять алгоритмы а не микрооптимизации под конкретную архитектуру. И чтобы все было более менее честно для других языков, ведь если какое-нибудь медленное O(n^2) c simd оптимизациями в C++ пройдет, а на Java сможет только O(n log n), то это будет не честно.
Оно и asm уже более менее забанено во многих местах:
Далее:
Тем не менее, если заниматья этим серьезно, то придется разбираться в чужом коде, читать разборы и общатся с людьми. Нет, могут быть отдельные саванты, которым просто от природы все знания уже даны, но эти исключения мы рассматривать особо не будем.
Отличная иллюстрация, почему успешная олимпиадная карьера практически гарантирует, что у человека будут основные необходимые навыки, чтобы быть отличным программистом. Потому что там "методом проб и ошибок", "не каким-то глубоким планированием" многого не добъешься.
По моему опыту даже последние интроверты и откровенные аутисты как раз с радостью говорят о том, что им интересно. И вот спортивным программированием обычно занимаются те, кому это интересно. И о коде и задачах эти "загоняемые в паническую петлю" могут разговаривать бесконечно без страха "сказать что-нибудь не то". Это же не обсуждение романтических отношений в офисе, а математика, где нельзя, даже перепутав знак или ошибившись в арифметике, нарушить какой-то этикет.
На высоком уровне и во многих популярных соревнованиях требуются навыки коммуникации. Давайте сойдемся на том, что это не гарант идеальных командных навыков для всех, кто хоть раз в жизни к этому прикоснулся, но командная работа там не такое уж и исключение.
Прочитал. Кроме секции "Как рассчитать коэффициенты линейной функции" математики там нет (если не считать формулу среднего арифметического).
А разве так можно? Эта система отсчета движется с ускорением. Слабо помню физику, но она точно не эквивалентна покоящейся системе отсчета. Тут, видимо просто трюк и упрощение объяснения. На самом деле те же силы можно найти в неподвижной системе счисления? Или в такой системе все еще можно считать силы и жопа там начинается только при релятивизме?
Метод подбора коэффициентов линейной функции по двум точкам - это теперь "сложный" материал?
А если игра какие-то ресурсы тянет с файловой системы, как это работает?
Сразу видно, человек с олимпиадным програмимрованием не знаком.
На олимпиадах их обычно нельзя использовать. Самый адский хак - это битовая магия какая-нибудь. И даже если ее потом использовать в индустриальном коде, ее запросто можно написать очень даже читаемой.
Самое пристижное и популярное соревнование - ICPC - командное. Трем людям дается один компьютер и они должны: разделять задачи, объяснять свое решение, писать его так, чтобы двое других поняли.
Даже без этого в олимпиадной среде надо уметь объяснять свое решение и понимать чужие. Потому что огромный пласт знаний передается живыми людьми друг-другу. Это очень ценный навык для коммандной работы.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу - единственное, на что они способны, это молча написать код.
Спортивное программирование действительно прививает определенный стиль кода, в основном выраженный в коротких непонятных называниях переменных. Потому что надо побыстрее решить задачу и потом этот код никто уже никогда поддерживать не будет.
Но от этой привычки можно избавиться буквально за пару недель при наличии код-ревью в процессе разработки.
Еще добавлю, что оно дает математическую базу и алгоритмическое мышление, которые потом отлично помогают с индустриальной работой. То самое умение формализовать задачу, выстроить решение и доказать его хотя бы самому себе. И когда вам встретится "олимпиадная" задача, вы ее вообще распознаете и сможете решить или хотя бы понять как искать решение.
Проблема в том, что генерировать бред на порядки проще, чем его опровергать, но я попробую.
Вот взяли вы 12 каких-то чисел. Вы могли бы точно так же написать числа от 1 до 12.
Вы потом долго расписываете как этот круг можно разбить на 2, 3, 4 и 6 кусков. Ну... да? Это потому что 12 делится на 2,3,4 и 6. При чем тут ваша модель разделения?
Свойства музыкальной шкалы и цветового круга никак не связаны с вашими числами, или вашими икосаэдрами, а их специально так составляли. Возьмем музыкальную шкалу. Соседние ноты отличаются по частоте в одинаковое количество раз (q=![\sqrt[12]{2}](https://habrastorage.org/getpro/habr/formulas/9/91/91c/91cf3d4c6f9d8f31c42b442ca97e4668.svg)
). Поэтому, если их брать через одну, через 2 и т.д., то получим ноты, опять же отличающиеся в одинаковое количество раз по частоте, что создает гармонию и красивое звучание. Поэтому именно такие через 1,2 и т.д. ноты и образуют аккорды. Никак с вашими числами это не связано.
Эти совпадения никак не следуют из вашей "модели", не несут какого-то особого смысла и не открвают никакую глубокую философскую истину.
Вот тут вы попытались как-то свою нумерологию привезать к математике... Но запутались.
У вас каждая промежуточная вершина по определению произведение двух соседних. Поэтому произведение двух соседних даст промежуточную вершиную. При чем тут ее делитель? Ну да, вы так постулировали, выписывать это как какое-то откровение - просто разувание материала для придания ему внушительного вида.
То, что все числа делители 900... Н у так вы 900 так и нашли, видимо. У любого набра чисел можно найти наименьший общий делитель. Он всегда есть.
Точно такие же "интересные" факты вы бы нашли, если бы изначально запихали числа в круг в порядке 2, 6, 3, 15, 5, 10.
Связь с икосаэдром и тетраэдром натянута. Вот у вас там в икосадре изумрудный (3^2*5) соседствует с 3, 5 и 3*5. Почему 3 получилась в квадрате, а 5 - нет? Вон, какие-то конкретные грани октаэдра дают "интересные" тройки, но тетраэдр симметричен, а остальные грани ничего интересного не дают. Хотя, если порыться, можно придумать что-то инетерсное о любом объекте, делая все ваши наблюдения субъективным поиском скрытого смысла и раздуванием значимости на пустом месте.
Вообще, вся ваша статья - это удивление каким-то симметриям цикличиской группы
и поиск каких-то совпадений.
Псевдофилосовский бред. Да симметрии красивы и чем более сложная группа симметрии, тем большими способами ее можно вращать, тем больше всяких псевдоглубоких наблюдений о ней можно сделать.
Поменьше общайтесь с нейросетками. Они подхалимы и будут хвалить даже полный бред.
Картинки разноцветные и красивые, смысла вообще ноль.
Если вы его используете для поиска достижимых вершин, веса ребер вам вообще безразличны.
Видимо, вы его используете для подсчета суммарных очков в поле и получения их в порядке возрастания, т.е. это не стандартная топологическая сортировка через bfs снизу-вверх, а сортировка вершин по расстоянию от начала через обход сверзу-вниз, которая гарантирует топологический порядок. Так?
В смысле. Оптимальный на злом поле должен брать в расчет злое поле. Но в принципе, я понял. На этом стоит заострить внимание в статье, что алгоритм считает лучшую стратегию в среднем, но играет против худшего случая.
И зачем там 1-2-bfs а не просто bfs?
Если запускать динамику рекурсивно, она сама только достижимые и обойдет.
Только сейчас заметил, у вас rand-angry иногда даже лучше best-angry. Какое же оно тогда best? Что-то у вас явно не так, раз есть стратегия набирающая больше очков оптимальной.
Потому что, как я выше писал, в случае злодея надо оценивать не матожидание а тупо финальный счет. Игрок выбирает ход с максимальной оценкой, злыдень - с минимальной.
Если по дереву ходов где-то внизу расходятся рядом есть очень плохой путь и очень хороший, то игрок-то этот очень плохой никогда не выберет. Но при счите матожидания, этот плохой путь портит оценку хода в начале и ваша best стратегия выбирает средний вариант, потому что рядом с ним не было варианта сильно ошибиться.
А в случае случайных клеток, надо считать матожидание только по выбору новой клетки и никак не по движению. Игрок выбирает одно из 4 направлений минимизируя оценку. Матожидание только по случайной величине делается, ход игрока - не случаен, вы его вычисляете.
Ведь каждый раз после хода игрока в случайной (или худшей) клетке появляется 2 или 4. А значит общая сумма очков на поле увеличится. Поэтому все поля топологически упорядочены по сумме очков. Тут нет циклов. Поэтому тут вообще работает динамика. Если бы были циклы, то пришлось бы решать систему линейных уравнений для поиска матожидания.
Простой способ не думать о порядке, это реализовать динамику сверху вниз, через рекурсию от начального состояния. Это просто пустое поле.
Не совсем понял, как вы тут применяете 1-2-bfs. Можно по-подробнее? Предполагаю, что это у вас топологическая сортировка снизу-вверх. Так тоже можно. Но проще же отсортировать все тупо по сумме очков. Можно даже подсчетом за линию.
Еще, если рассматривать "злобную" клетку, то у вас получается игра двух игроков - один сдвигает поле, другой кидает в пустую клетку 2 или 4. Первый максимизирует сумму, второй минимизирует. Тут уже можно рассматривать не матожидание, а минимакс: какое максимальное количество очков может себе гарантировать первый игрок.
Еще вопрос, когда вы считаете, что игра остановилась?
Проводили ли вы какую-то дедупликацию состояний, вроде поворотов/отражений? Казалось, бы если гравитационный ход заменить на поворот и всегда падение вниз, то все состояния будут сильно более похожи: всего 4^3 вариантов какие клетки вообще могут быть заполнены, в каждом столбе количество очков должно различатся у соседних клеток.
У вас нет алгоритма как такового на самом деле. У вас формулировка задачи для решателя. Да, там n^2m переменных и очень много ограничений, и их надо циклами сгенерировать, но это не очень достойно гордого названия "алгоритм".
Математическая формулировка - это тоже работа и это стоит статьи, но я бы не называл это алгоритмом.
Там где у вас формула для целевой функции L() у вас неточность в нотации. Сумма по переменной i, означающей ребро, а внутри u_ij, но вот это i внутри - это уже узел, а не ребро. Правильно было бы записать сумму по 1 <= i,j <=n, Где n - количество узлов. Но это мелочь, просто в глаза бросилось.
А вопрос по делу: как работает оптимизация, что за решатель? У вас линейные ограничения, но целевая функция не линейная и даже не квадратичная. Как должно оно работает?
Кажется, вашу задачу можно свести к задаче линейного программирования, если все потоки и ограничения сделать целыми. Вроде как пропускная способность бит/с и потоки тоже в неделимых битах/с считать. Тогда можно разбить каждое ребро с пропускной способностью C на кучу параллельных ребер с пропускными способностями 1 бит/c и назначить им цены: 0/C-1/(C-1), 2/(C-2) - 1/(C-1)... ,(C-1)/1- (C-2)/2. Фактически, цена ребра - это разность L(k)-L(k-1) - на сколько увеличится штраф по изначальному ребру, если по нему пустить дополнительную единицу потока, пока там уже было k-1 потока. Поскольку целевая функция выпуклая от полного потока по ребру, то приращения строго возрастают при увеличении потока, поэтому просто взяв k минимальных параллельных ребер вы получите точно целевую функцию при потоке k по изначальному ребру. И вот уже задача свелась к мульти-потоку в графе. Тут уже линейные решатели (при чем даже не целочисленные) все решат, возможно даже быстрее. А если поток всего один, то задача вообще за полиномиальное время решается.
С другой стороны, это сильно увеличивает количество ребер в графе. Но тут можно балансировать точность и скорость. Если считать не в бит/c а кбит/c или 100кбит/c, то вы уменьшаете количество параллельных ребер и ускоряете решение.
Гуглите в сторону выпуклых целевых функций для максимального потока в графе.
Интересная тема, но на практике не применима. Таскать конкретную LLM-ку с архиватором слишком накладно. А польза весьма небольшая. Оно сжимает только человеческий текст. Даже не plaintext данные. Те же логи оно уже будет предсказывать плохо. А человеческий текст итак неплохо сжимается классическими алгоритмами.