А вы могли бы какой-нибудь неплохой солвер уловно на «поиграться» порекомендовать (в идеале хочу, чтобы в моём арсенале был инструмент «по-быстрому решить какую-нибудь задачку с ограничениями, при этом достаточно современный).
ПС
По вашему вопросу: я вполне понимаю почему я не хочу пролог — они зафиксировали порядок перебора (ну типа чтобы сделать ЯП „взрослым“ — детерминированно работающим в разных реализациях).
Только в этом и проблема — в случае NP задач надо настолько глубоко вдаваться во внутренние детали работы пролога, что проще то же самое на условном С \ Java написать чем „оптимизировать“ пролог.
Объясните какое это имеет отношение:
— к обсуждаемой теме: «большие юниты в гексо-сетке».
— к конкретному вопросу: «визуализация дискретных метрик на экране пользователя».
Возможно вы переубедите меня и скинете ссылки на игры, в которых на гексо клетке есть движущиеся юниты из 3\4 (не 7) гексов. Я посмотрю и если игры хороши — признаю что сложности устранимы.
Мне таких неизвестно и я подозреваю не в последнюю очередь из-за сложностей описанных мною ниже.
Более того, мои вкусовые пристрастия сформировались на HoMM2 / HoMM3. И когда я впервые увидел HMM5 я плевался. Но когда распробовал — понял насколько квадратная метрика лучше для глубокой тактической боёвки, чем шестиугольная.
Юнит из трёх гексов треугольником — полный аналог квадратного 2х2.
Нет. Совсем другое.
Он «симметричный» по осям: 0-60-120-180-240-300- градусов.
Но человеческий мозг ожидает что он будет симметричным по осям: 0-90-180-270 (чего он сделать не может)
Т.е. вот такой: ":. " юнит при рассмотрении человеком несимметричный и уродливый.
А при попытке «поворачивать» его при изменении направления будет ещё хуже — он может просто «застрять».
То, что искажения будут при любой дискретной метрике боле-менее понятно. Всё-таки вопрос про практику применения, а не исторический экскурс.
Почему сегодня, для тактики, люди выбирают шестиугольную сетку. Исключительно для придания игре «тёплого лампового» вида или есть ещё какие-то соображения.
А больших юнитов можно сделать из трёх гексов.
Ну я не знаю тактических игр с гексами и большими юнитами.
С ходу приходит в голову, что любой размер до 7гексов асимметричен по разным осям, что вызывает сразу кучу проблем, от «визуального дискомфорта», до «правила обхода препятствий».
Вот какой вопрос возник: а почему сетка гексагональная?
Ведь 4-угольная сетка позволяет делать «больших» юнитов 2х2, что кардинально увеличивает тактическое разнообразие вариантов.
Например, не так важно, занимает компиляция микросервис 20 или 30 секунд. Собственно как и неважно, занимает ли сборка 20 минут или 30 минут (и то, и другое — чудовищно много).
В качестве замечания: как раз 20 или 30 секунд вполне может быть значимая разница, т.к. «не отвлечься за 20 секунд, но отвлечься за 30» — вполне возможный сценарий.
Есть некоторый порог, когда «незанятый текущей задачей мозг» переключает фокус внимания, откуда он рискует вынырнуть с вытравленным кэшем ;)
И по личным ощущениям этот порог времени в районе минуты.
Извините, что немного сумбурно изложил вопрос.
У меня, как у человека на математику не забивавшего и даже интересовавшегося \ интересующегося, но всё-таки математического образования и соответствующего бэкграунда не имеющего сложилось мнение, что «базово» тригонометрические ф-ии это решения диф.уравнений.
Вы говорите, что «базово» тригонометрические ф-ии это разложение в ряд.
Естественно, любой современный статический анализатор отслеживает изменение значения переменных. Если переменная не меняется, будет сообщение. Если меняется, сообщения не будет. Для этого используется технология анализа потока данных.
А как при этом учитывается возможность алиасов указателей (насколько я помню это неразрешимая, в общем случае, проблема для языков с возможностями C \C++)?
Да вы правы.
Действительно это зависимость другого рода и действительно Rust не обещает мне консистентность данных, а только отсутсвие ошибок с указателями (насколько я адекватно нагуглил после вашего комментария — разумеется прочитать и понять всю Rust Book я не упел).
Тут может быть только замечание, оно уже было произнесено, но хотелось бы его проартикулировать ещё раз.
С одной стороны «никто не виноват» вероятно циклические структуры данных — это действительно математически очень сложная штука раз такой паттерн вообще нужен.
Но мои ожидания всё-таки были другими: что инструмент сделает мой «список» безопасным оставив прежнюю производительность, а не вынудит использовать структуры данных переводящие «локальную опасную» ошибку в «неопасную и `менее локальную` ».
Мои ожидания — вроде как моя проблема (тем более циклические СД — наверное действительно сложно), а с другой стороны не упоминание довольно известных и актуальных проблем в популяризирующих материалах — не очень хороший тон.
Когда вы сохранили «Vec» + «index_in_vec = 3» (вместо указателя \ ссылки) — то зависимость у вас логически никуда не делась, а в терминах доступных Borrow Checker её нет.
Ну как бы это уже немного обманывает ожидания, которые я имел от Раста исходя из постов на Хабре (сейчас по сути пытаюсь для себя решить — надо ли мне это (изучение Rust)? ).
И такие моменты очень сильно смущают.
Мы создали такую хорошую и такую строгую систему (Borrow Checker), что один из паттернов программирования на языке — им не пользоваться // я несколько утрирую.
Технически может быть и ок:
— удаление из такого массива ассимптотически дороже
+ массивы кэш-френдли, а читаем мы чаще, чем удаляем.
Но идейно: пока у вас всё хорошо инкапсулировано в хорошо отлаженной библиотеке — всё хорошо.
Но как только вы такой поттерн применяете в своём коде — вы сильно мешаете ошибки прикладного кода с ошибками структур данных.
Это меня очень смущает (до такой степени, что выглядит как антипаттерн).
По теме: не вижу конструктивного способа продолжения спора (мне видится, что всё это чрезвычайно неэффективно, по скорости, на ваших задачах было ок) — слишком много несовпадений в параметрах сравнения.
Когда / если дойдут руки (на других уже задачах) — обращусь к вам. Спасибо.
Но даже в таком представлении (где вы непонятно что выигрываете — вверх по зависимостям ходить требуется довольно регулярно (*)) если в графе цикл: a -> b -> a то у вас тоже цикл.
В принципе — потому, что IR содержит графы с циклами.
Технически потому, что представление графов: вершина содержит список дуг, дуга — два указателя на вершины технически наиболее удобно.
Поскольку эти графы сильно разряжены, активно изменяются, и большие (получить граф на 1000000 вершин (gcc -lto) дело не то, чтобы обычное, но и необычным не назовёшь), — то остальные представления проигрывают этому.
ПС
Вот смотрю материалы по Rust — и похоже(*) видел альтернативу циклической структуры, где вместо указателя содержался НОМЕР элемента в соответствующем векторе.
Ну т.е. это пиздец товарищи, не для такого мы коммунизм строили, чтобы значит ошибки из низкого уровня переносить в логику программы.
*) похоже — потому, что это бесплатная лекция с выложенного курса. Ролик без материалов.
>> И вы упорно не отвечаете, что, по-вашему, делает написание компиляторов на плюсах более удобным, и стоит ли мне на всякий случай переписывать (или в будущем писать) свои язычки на плюсах.
С фронтэндами языков лично я знаком лишь шапошно, но вот как написать бэкэнд на Хаскеле представляю крайне слабо (ну да сейчас всё в LLVM заворачивают):
На бэкэнде же ну не знаю 90% преобразований подпадают под один или оба паттерна:
— проанализировать граф и что-то в нём преобразовать (воможно транзитивно)
— заменить одно представление CFG-узла другим (идти «сверху вниз» по куску графа, храня какое-то очень большое состояние и меняя операции, в соответствии с состоянием — распределение регистров, IceBreaker, ...).
По-моему и то и то на Хаскеле писать больно (ну или не менее больно чем на условной Java).
Если рекомендуете — спасибо, посмотрю.
ПС
По вашему вопросу: я вполне понимаю почему я не хочу пролог — они зафиксировали порядок перебора (ну типа чтобы сделать ЯП „взрослым“ — детерминированно работающим в разных реализациях).
Только в этом и проблема — в случае NP задач надо настолько глубоко вдаваться во внутренние детали работы пролога, что проще то же самое на условном С \ Java написать чем „оптимизировать“ пролог.
— к обсуждаемой теме: «большие юниты в гексо-сетке».
— к конкретному вопросу: «визуализация дискретных метрик на экране пользователя».
Мне таких неизвестно и я подозреваю не в последнюю очередь из-за сложностей описанных мною ниже.
Более того, мои вкусовые пристрастия сформировались на HoMM2 / HoMM3. И когда я впервые увидел HMM5 я плевался. Но когда распробовал — понял насколько квадратная метрика лучше для глубокой тактической боёвки, чем шестиугольная.
Нет. Совсем другое.
Он «симметричный» по осям: 0-60-120-180-240-300- градусов.
Но человеческий мозг ожидает что он будет симметричным по осям: 0-90-180-270 (чего он сделать не может)
Т.е. вот такой: ":. " юнит при рассмотрении человеком несимметричный и уродливый.
А при попытке «поворачивать» его при изменении направления будет ещё хуже — он может просто «застрять».
Почему сегодня, для тактики, люди выбирают шестиугольную сетку. Исключительно для придания игре «тёплого лампового» вида или есть ещё какие-то соображения.
Ну я не знаю тактических игр с гексами и большими юнитами.
С ходу приходит в голову, что любой размер до 7гексов асимметричен по разным осям, что вызывает сразу кучу проблем, от «визуального дискомфорта», до «правила обхода препятствий».
Ведь 4-угольная сетка позволяет делать «больших» юнитов 2х2, что кардинально увеличивает тактическое разнообразие вариантов.
В генетическом алгоритме очень легко просмотреть «трещину», а человек её очень быстро находит.
В качестве замечания: как раз 20 или 30 секунд вполне может быть значимая разница, т.к. «не отвлечься за 20 секунд, но отвлечься за 30» — вполне возможный сценарий.
Есть некоторый порог, когда «незанятый текущей задачей мозг» переключает фокус внимания, откуда он рискует вынырнуть с вытравленным кэшем ;)
И по личным ощущениям этот порог времени в районе минуты.
У меня, как у человека на математику не забивавшего и даже интересовавшегося \ интересующегося, но всё-таки математического образования и соответствующего бэкграунда не имеющего сложилось мнение, что «базово» тригонометрические ф-ии это решения диф.уравнений.
Вы говорите, что «базово» тригонометрические ф-ии это разложение в ряд.
Почему?
А как при этом учитывается возможность алиасов указателей (насколько я помню это неразрешимая, в общем случае, проблема для языков с возможностями C \C++)?
извините, а почему не решение уравнения:
f(x) = -f''(x)
f(0) = 1
Действительно это зависимость другого рода и действительно Rust не обещает мне консистентность данных, а только отсутсвие ошибок с указателями (насколько я адекватно нагуглил после вашего комментария — разумеется прочитать и понять всю Rust Book я не упел).
Тут может быть только замечание, оно уже было произнесено, но хотелось бы его проартикулировать ещё раз.
С одной стороны «никто не виноват» вероятно циклические структуры данных — это действительно математически очень сложная штука раз такой паттерн вообще нужен.
Но мои ожидания всё-таки были другими: что инструмент сделает мой «список» безопасным оставив прежнюю производительность, а не вынудит использовать структуры данных переводящие «локальную опасную» ошибку в «неопасную и `менее локальную` ».
Мои ожидания — вроде как моя проблема (тем более циклические СД — наверное действительно сложно), а с другой стороны не упоминание довольно известных и актуальных проблем в популяризирующих материалах — не очень хороший тон.
И такие моменты очень сильно смущают.
Мы создали такую хорошую и такую строгую систему (Borrow Checker), что один из паттернов программирования на языке — им не пользоваться // я несколько утрирую.
— удаление из такого массива ассимптотически дороже
+ массивы кэш-френдли, а читаем мы чаще, чем удаляем.
Но идейно: пока у вас всё хорошо инкапсулировано в хорошо отлаженной библиотеке — всё хорошо.
Но как только вы такой поттерн применяете в своём коде — вы сильно мешаете ошибки прикладного кода с ошибками структур данных.
Это меня очень смущает (до такой степени, что выглядит как антипаттерн).
Когда / если дойдут руки (на других уже задачах) — обращусь к вам. Спасибо.
Но даже в таком представлении (где вы непонятно что выигрываете — вверх по зависимостям ходить требуется довольно регулярно (*)) если в графе цикл: a -> b -> a то у вас тоже цикл.
*) в оптимизирующем компиляторе.
>> А зачем вам там циклические структуры? :)
Не понял вопроса.
В принципе — потому, что IR содержит графы с циклами.
Технически потому, что представление графов: вершина содержит список дуг, дуга — два указателя на вершины технически наиболее удобно.
Поскольку эти графы сильно разряжены, активно изменяются, и большие (получить граф на 1000000 вершин (gcc -lto) дело не то, чтобы обычное, но и необычным не назовёшь), — то остальные представления проигрывают этому.
ПС
Вот смотрю материалы по Rust — и похоже(*) видел альтернативу циклической структуры, где вместо указателя содержался НОМЕР элемента в соответствующем векторе.
Ну т.е. это
пиздец товарищи, не для такого мы коммунизм строили, чтобызначит ошибки из низкого уровня переносить в логику программы.*) похоже — потому, что это бесплатная лекция с выложенного курса. Ролик без материалов.
> по-моему
В смысле я не знаю как это реализовано.
Я вас позже спрошу какую библиотеку посмотреть (надо сразу руками щупать, пока не дошли).
А сейчас объясните плз, как это идейно реализовано, ведь immutable data несовместимо с циклическими структурами данных, при наивной реализации.
С фронтэндами языков лично я знаком лишь шапошно, но вот как написать бэкэнд на Хаскеле представляю крайне слабо (ну да сейчас всё в LLVM заворачивают):
На бэкэнде же ну не знаю 90% преобразований подпадают под один или оба паттерна:
— проанализировать граф и что-то в нём преобразовать (воможно транзитивно)
— заменить одно представление CFG-узла другим (идти «сверху вниз» по куску графа, храня какое-то очень большое состояние и меняя операции, в соответствии с состоянием — распределение регистров, IceBreaker, ...).
По-моему и то и то на Хаскеле писать больно (ну или не менее больно чем на условной Java).