Ну да. Мы можем рассматривать каждую пару как отдельное линейное уравнение, а всю систему как СЛАУ. Тогда последовательное решение каждой коллизии в несколько проходов будет эквивалентно методу итераций для решения СЛАУ. Но предполагаю, что tony-space предлагает что-то более оптимальное.
Вот тут можно посмотреть как Nexto играет против типового игрока и его контроль мяча.
И я уверен, что можно научить бота намеренно стараться держать мяч в воздухе. Вопрос просто в подборе верных наград, гиперпараметров обучения и времени.
Я использовал похожие типы наград в первоначальном варианте, но, как я писал, лучше сработали более простые варианты. Если придумать правильные более хитрые типы наград, то бот быстрее будет обучаться, но с другой стороны это может его ограничивать для более хитрых тактик. Например, иногда выгоднее подвести мяч к своим воротам, но зато получить контроль мяча. В целом при достаточном времени обучения, бот все равно найдёт правильную тактику, и в данный момент мне кажется более перспективным мотивировать бота изучать больше вариантов стратегии. Например, я вижу, что он не пытается использовать задний ход, хотя моментами это было бы очень полезно. Для решения таких проблем как раз существует entropy loss, этот лосс заставляет сеть быть менее уверенной в своих решениях, и она в процессе обучение пробует больше других вариантов.
Тогда это будет не блэкджек. Но и в покере, например, ситуация будет уже посложнее. Если действовать просто по инструкции, то тогда поведение станет слишком читаемым. Там нужно будет добавить элемент случайности при выборе следующего действия.
Это скорее была шутка. Игра изначально сделана таким образом, чтобы дилер выигрывал с небольшим перевесом, иначе бы в казино бы её не использовали. Можно перевести шансы победы в свою пользу, но уже играя ставками и считая насколько колода становиться "горячей". Т.е. грубо говоря, считаем сколько в колоде остаётся 10к (дам, вальтов, королей), чем их больше, тем выше вероятность получить перебор у дилера, тем делаем ставку выше. А сама стратегия остаётся той же. Только в реальности ещё нужно учитывать сплиты и количество колод в игре.
В первую очередь идёт проект/идея -> следом за ней терминология. Если будет много работ от русскоязычных авторов, будет больше вероятность того, что будут использовать термины на русском языке.
Вам что важнее, чтобы было понятнее для людей в контексте, или чтобы сохранить чистоту русского языка?
В любом случае хабр больше про идеи, а не про русский язык
Ну может быть. Однако, когда attention в данном контексте имеют ввиду именно тот самый механизм внутри Attention-based слоя. Т.е. ссылаются на термин, который широко используется в актуальных статьях. А термин "механизм внимания" не так распространён, и, например, у меня не сразу бы возникла эта ассоциация. Даже в той статье все эти термины дублируются на английском по этой причине.
К тому же global attention - это достаточно свежий термин. В итоге придётся придумывать свой перевод для него? Глобальное внимание будет совсем непонятно звучать.
Слово аттеншн используется не в значении "внимание". Тут это действительно отдельные термины, у которых свое значение.
Вообще вопрос как правильно переводить термины, тут и аттеншн выглядит криво, и матрицей внимания это не назовёшь. И русских терминов и не появится, учитывая, что вся информация на английском.
По опыту - лучше использовать библиотеку Eigen, чем писать свою матричную математику. Ее можно использовать просто как header-only, время компиляции может увеличиться, но это потенциально избавит от многих проблем.
Может написать приложение на телефон, чтобы по фото домофона определять тип ключа? И уменьшить таким образом множество для перебора? Насколько это реально?
В скрипте для Unity уже реализовано простенькое сглаживание.
Но по хорошему я бы добавил еще один этап уточнения пололожения. На этом этапе я бы задал функцию ошибки, на которой бы выполнялась оптимизация. В самой функции была бы включена еще разница текущего и предыдущего положения камеры в пространстве, т.е. искалось бы такое решение, которое бы пыталось лучшим образом описать текущие данные и которое бы как можно меньше отличались от предыдущего решения.
Этот у меня подход неплохо работал в этом проекте
Я использовал вектора разного размера, потому что большинство операций могут работать в любой размерности. А кватернион — это 4х мерный вектор, вот и вся связь.
Кватернионы хороши, но не особо нужны для дальнейших задач в этом направлении
Я так понял там было предложение использовать структурный свет. Несколько кадров с спроецированной сеткой — для вычисления геометрии, и один кадр без неё — для вычисления цвета точек.
И какой вообще софт использовали?
Ну да. Мы можем рассматривать каждую пару как отдельное линейное уравнение, а всю систему как СЛАУ. Тогда последовательное решение каждой коллизии в несколько проходов будет эквивалентно методу итераций для решения СЛАУ.
Но предполагаю, что tony-space предлагает что-то более оптимальное.
Спасибо!
Вот тут можно посмотреть как Nexto играет против типового игрока и его контроль мяча.
И я уверен, что можно научить бота намеренно стараться держать мяч в воздухе. Вопрос просто в подборе верных наград, гиперпараметров обучения и времени.
Спасибо!
PPO - proximal policy optimization, метод, предложенный OpenAI.
Я использовал похожие типы наград в первоначальном варианте, но, как я писал, лучше сработали более простые варианты. Если придумать правильные более хитрые типы наград, то бот быстрее будет обучаться, но с другой стороны это может его ограничивать для более хитрых тактик. Например, иногда выгоднее подвести мяч к своим воротам, но зато получить контроль мяча. В целом при достаточном времени обучения, бот все равно найдёт правильную тактику, и в данный момент мне кажется более перспективным мотивировать бота изучать больше вариантов стратегии. Например, я вижу, что он не пытается использовать задний ход, хотя моментами это было бы очень полезно. Для решения таких проблем как раз существует entropy loss, этот лосс заставляет сеть быть менее уверенной в своих решениях, и она в процессе обучение пробует больше других вариантов.
Тогда это будет не блэкджек. Но и в покере, например, ситуация будет уже посложнее. Если действовать просто по инструкции, то тогда поведение станет слишком читаемым. Там нужно будет добавить элемент случайности при выборе следующего действия.
Это скорее была шутка. Игра изначально сделана таким образом, чтобы дилер выигрывал с небольшим перевесом, иначе бы в казино бы её не использовали. Можно перевести шансы победы в свою пользу, но уже играя ставками и считая насколько колода становиться "горячей". Т.е. грубо говоря, считаем сколько в колоде остаётся 10к (дам, вальтов, королей), чем их больше, тем выше вероятность получить перебор у дилера, тем делаем ставку выше. А сама стратегия остаётся той же. Только в реальности ещё нужно учитывать сплиты и количество колод в игре.
Почему?
Используется в качестве названия особой схемы архитектуры нейроной сети.
В первую очередь идёт проект/идея -> следом за ней терминология. Если будет много работ от русскоязычных авторов, будет больше вероятность того, что будут использовать термины на русском языке.
Вам что важнее, чтобы было понятнее для людей в контексте, или чтобы сохранить чистоту русского языка?
В любом случае хабр больше про идеи, а не про русский язык
Ну может быть. Однако, когда attention в данном контексте имеют ввиду именно тот самый механизм внутри Attention-based слоя. Т.е. ссылаются на термин, который широко используется в актуальных статьях. А термин "механизм внимания" не так распространён, и, например, у меня не сразу бы возникла эта ассоциация. Даже в той статье все эти термины дублируются на английском по этой причине.
К тому же global attention - это достаточно свежий термин. В итоге придётся придумывать свой перевод для него? Глобальное внимание будет совсем непонятно звучать.
del
Слово аттеншн используется не в значении "внимание". Тут это действительно отдельные термины, у которых свое значение.
Вообще вопрос как правильно переводить термины, тут и аттеншн выглядит криво, и матрицей внимания это не назовёшь. И русских терминов и не появится, учитывая, что вся информация на английском.
По опыту - лучше использовать библиотеку Eigen, чем писать свою матричную математику. Ее можно использовать просто как header-only, время компиляции может увеличиться, но это потенциально избавит от многих проблем.
Только в деталях это работает немного по-разному
Может написать приложение на телефон, чтобы по фото домофона определять тип ключа? И уменьшить таким образом множество для перебора? Насколько это реально?
Пицца - это Европа? А у России какая иконка?
Но по хорошему я бы добавил еще один этап уточнения пололожения. На этом этапе я бы задал функцию ошибки, на которой бы выполнялась оптимизация. В самой функции была бы включена еще разница текущего и предыдущего положения камеры в пространстве, т.е. искалось бы такое решение, которое бы пыталось лучшим образом описать текущие данные и которое бы как можно меньше отличались от предыдущего решения.
Этот у меня подход неплохо работал в этом проекте
Я использовал вектора разного размера, потому что большинство операций могут работать в любой размерности. А кватернион — это 4х мерный вектор, вот и вся связь.
Кватернионы хороши, но не особо нужны для дальнейших задач в этом направлении
Я так понял там было предложение использовать структурный свет. Несколько кадров с спроецированной сеткой — для вычисления геометрии, и один кадр без неё — для вычисления цвета точек.
И какой вообще софт использовали?
На выходе получаем трёхмерную модель, которую можно сохранять.