Т.е. Kotlin это язык для frontend? Или в чем задачи разные?
Стадия компилятора не связана с классическим frontend - это внутренности компилятора. Но на Kotlin все же можно писать под Wasm/JS, а также под iOS (на самом деле Native в целом). И рантаймы там действительно другие, не JVM.
Это уже не хуже аргументов, перечисленных в статье: про дешевизну, костность мышления, технологическую изоляцию. А слово мог есть даже в заголовке: "Как мир мог не стать двоичным".
Что значит анализ троичной системы через двоичную? Я уже два раза написал, что двоичная тут используется только для сравнения и через нее ничего не выражается. Есть функция Вебба, которая определяется так в любой многозначной логике:
Через нее выражаются любые другие функции в двоичной, троичной или любой другой многозначной логике. Например, в двоичной логике базовые операции через нее выржаются так:
~x = W(x, x)
x & y = ~(~x | ~y) = W(W(x, x), W(y, y))
x | y = Inc(W(x, y)) = W(W(x, y), W(x, y))
В троичной вот так:
Inc(x) = W(x, x)
Dec(x) = Inc(Inc(x))
~x = W(W(Dec(x), Inc(x)), Inc(W(Dec(x), x))
x & y = ~(~x | ~y)
x | y = Inc(Inc(W(x, y))
Если далее заменить все Inc и Dec на функцию Вебба, то получится монстр. В двоичной логике формулы занимают намного меньше места (видно, что даже если все раскрыть, то получается не так уж и страшно).
С теоретической точки зрения через функцию Вебба выражаются все остальные функции в любой многозначной логике. Однако она не практична и формулы получаются слишком громоздкими. Хотя в троичной логике все намного более монстроуозней по сравнению с двоичной.
Она бы не поехала дальше все равно из-за технических ограничений и теоретической сложности, даже если бы троичные компы изобрели раньше в условном Интеле. И причины прерывания программы, перечисленные в статье, несущественные по сравнению с этим.
А еще троичные булевы операции сложнее, то есть сложность не только технологическая, но и теоретическая. Например, для вычисления функции Вебба (через нее выражаются все остальные функции) требуется намного больше транзисторов. Есть более подробная инфа: https://math.stackexchange.com/q/253861
Если это хорошо обученная нейронка, то она будет сильно играть даже без перебора, чисто на предсказании. Однако таких пока что не существует для Точек (но мы работаем над этим). И в браузере на клиенте в теории она тоже сможет работать.
Потому что боты - это не просто более менее стандартный сайт. Для них самих нужно нейросеть обучать (ну если конечно есть цель сделать бота, с которым было бы интересно играть). Вряд ли с этим хоть как-то сейчас LLM справится.
Если что - я с единомышленниками работаем над созданием бота сверхчеловеческого уровня для классических Точек (в которых нужно захватывать точки, а не территорию). Делаю его на основе открытого движка KataGo: https://github.com/KvanTTT/KataGoDots
Да, в целом правила Точек легче правил Го, однако в Точках стандартный размер 39*32, что намного превышает стандартный размер в Го 19*19 - это является усложняющим фактором.
Попробовать поиграть с уже существующими ботами можно на площадке https://notago.ru (они сильны в тактике, но все еще имеют слабые стороны, которые легко эксплуатировать).
Цель: в классических Точках - окружить как можно больше точек соперника, в Го - замкнуть как можно большую территорию (но захваченные камни идут в бонус).
В Точках можно создавать окружения с пустыми позициями внутри, в Го - нет.
В Точках позиции внутри окружения остаются окруженными навсегда, в Го - захваченные камни исчезают и их позиции снова становятся валидными для следующих ходов. Это вносит новую концепцию в игру - Ко. Суть в том, что нельзя, чтобы следующий ход в точности повторял предыдущую позицию на доске (иначе это может приводить к зацикливанию).
В Точках нельзя спасовать, т.к. это бессмысленно, в Го спасовать можно и иногда нужно, чтобы закончить игру. Зато в Точках можно заземлиться, чтобы тоже закончить игру, когда дальнешее продолжение не имеет смысла.
В Точках стандартное поле считается 39*32, в Го - 19*19.
Цель игры - захватит как можно бОльшую территорию.
Именно такая? Обычно в русских Точках нужно захватить как можно больше точек соперника, а территория никак не учитывается. И что является территорией в вашем случае: площадь или количество позиций внутри окружения? Последнее кажется более правильным. Как при этом учитываются точки внутри окружений, это +1 очко как в Го?
Сложность была в том, что надо было выявлять замкнутые фигуры, обход по древу и другие логические "издержки".
На самом деле этот алгоритм не особо сложный, дерево не обязательно использовать. Можно использовать алгоритм заливки или последовательный обход точек внутри потенциального контура.
Пришла идея считать кол-во окрашенных пикселей в захваченной территории.
Если так считается итоговая территория, то это очень плохая идея. Если территория - это площадь, то достаточно посчитать количество треугольников внутри окружения и умножить на 0.5, т.к. треугольник - это минимально возможная площадь. Если позиции, то просто посчитать алгоритмом заливки.
Хассабис не согласился с пессимистичной оценкой. "Шахматы сейчас популярнее, чем когда-либо. Никому не интересно смотреть, как компьютеры играют с компьютерами — нам интересно смотреть, как Магнус Карлсен играет против других топ-игроков", — ответил он.
Прям так и сказал? Если да, то меня разочаровывает его ошибочное обобщение. Мне интересно смотреть как компьютеры играют с компьютерами (или с людьми). Я бы даже сказал, что это интересней, чем партии людей с людьми (правда я в основном игрой Го интересуюсь).
Если пример простой, то лезть за этим инструментом может оказаться дольше и дороже, чем выдать предобученное значение. Собственно как и у человека (зачем лезть в калькулятор если нужно сложить 3 + 4?)
Стадия компилятора не связана с классическим frontend - это внутренности компилятора. Но на Kotlin все же можно писать под Wasm/JS, а также под iOS (на самом деле Native в целом). И рантаймы там действительно другие, не JVM.
Это уже не хуже аргументов, перечисленных в статье: про дешевизну, костность мышления, технологическую изоляцию. А слово мог есть даже в заголовке: "Как мир мог не стать двоичным".
Что значит анализ троичной системы через двоичную? Я уже два раза написал, что двоичная тут используется только для сравнения и через нее ничего не выражается. Есть функция Вебба, которая определяется так в любой многозначной логике:
Через нее выражаются любые другие функции в двоичной, троичной или любой другой многозначной логике. Например, в двоичной логике базовые операции через нее выржаются так:
В троичной вот так:
Если далее заменить все
IncиDecна функцию Вебба, то получится монстр. В двоичной логике формулы занимают намного меньше места (видно, что даже если все раскрыть, то получается не так уж и страшно).Нет - монстроуозность образуется просто при работе с троичной логикой. То, что написано в комментарии выше, не связано с двоичной логикой.
С теоретической точки зрения через функцию Вебба выражаются все остальные функции в любой многозначной логике. Однако она не практична и формулы получаются слишком громоздкими. Хотя в троичной логике все намного более монстроуозней по сравнению с двоичной.
Она бы не поехала дальше все равно из-за технических ограничений и теоретической сложности, даже если бы троичные компы изобрели раньше в условном Интеле. И причины прерывания программы, перечисленные в статье, несущественные по сравнению с этим.
А еще троичные булевы операции сложнее, то есть сложность не только технологическая, но и теоретическая. Например, для вычисления функции Вебба (через нее выражаются все остальные функции) требуется намного больше транзисторов. Есть более подробная инфа: https://math.stackexchange.com/q/253861
Она не только сложней, но скорей всего и неэффективней и менее стабильная.
Тогда вообще не вижу даже теоретических плюсов в архитектуре на тритах, если все это можно сэмулировать с помощью обычных двоичных бит.
Если это хорошо обученная нейронка, то она будет сильно играть даже без перебора, чисто на предсказании. Однако таких пока что не существует для Точек (но мы работаем над этим). И в браузере на клиенте в теории она тоже сможет работать.
Потому что боты - это не просто более менее стандартный сайт. Для них самих нужно нейросеть обучать (ну если конечно есть цель сделать бота, с которым было бы интересно играть). Вряд ли с этим хоть как-то сейчас LLM справится.
Если что - я с единомышленниками работаем над созданием бота сверхчеловеческого уровня для классических Точек (в которых нужно захватывать точки, а не территорию). Делаю его на основе открытого движка KataGo: https://github.com/KvanTTT/KataGoDots
Да, в целом правила Точек легче правил Го, однако в Точках стандартный размер 39*32, что намного превышает стандартный размер в Го 19*19 - это является усложняющим фактором.
Попробовать поиграть с уже существующими ботами можно на площадке https://notago.ru (они сильны в тактике, но все еще имеют слабые стороны, которые легко эксплуатировать).
Цель: в классических Точках - окружить как можно больше точек соперника, в Го - замкнуть как можно большую территорию (но захваченные камни идут в бонус).
В Точках можно создавать окружения с пустыми позициями внутри, в Го - нет.
В Точках позиции внутри окружения остаются окруженными навсегда, в Го - захваченные камни исчезают и их позиции снова становятся валидными для следующих ходов. Это вносит новую концепцию в игру - Ко. Суть в том, что нельзя, чтобы следующий ход в точности повторял предыдущую позицию на доске (иначе это может приводить к зацикливанию).
В Точках нельзя спасовать, т.к. это бессмысленно, в Го спасовать можно и иногда нужно, чтобы закончить игру. Зато в Точках можно заземлиться, чтобы тоже закончить игру, когда дальнешее продолжение не имеет смысла.
В Точках стандартное поле считается 39*32, в Го - 19*19.
Именно такая? Обычно в русских Точках нужно захватить как можно больше точек соперника, а территория никак не учитывается. И что является территорией в вашем случае: площадь или количество позиций внутри окружения? Последнее кажется более правильным. Как при этом учитываются точки внутри окружений, это +1 очко как в Го?
На самом деле этот алгоритм не особо сложный, дерево не обязательно использовать. Можно использовать алгоритм заливки или последовательный обход точек внутри потенциального контура.
Если так считается итоговая территория, то это очень плохая идея. Если территория - это площадь, то достаточно посчитать количество треугольников внутри окружения и умножить на 0.5, т.к. треугольник - это минимально возможная площадь. Если позиции, то просто посчитать алгоритмом заливки.
Прям так и сказал? Если да, то меня разочаровывает его ошибочное обобщение. Мне интересно смотреть как компьютеры играют с компьютерами (или с людьми). Я бы даже сказал, что это интересней, чем партии людей с людьми (правда я в основном игрой Го интересуюсь).
У Хабра много проблем с Markdown, и он не сочетается с GitHub Flavored Markdown. Несколько лет назад я даже разработал конвертер в формат хабра.
Если пример простой, то лезть за этим инструментом может оказаться дольше и дороже, чем выдать предобученное значение. Собственно как и у человека (зачем лезть в калькулятор если нужно сложить 3 + 4?)
Я думаю что-то типа такого уже и так используется в современных ассистентах.
А зачем? Там очень большое ветвление и глубина, так что на ничью играть практически невозможно (имеется в виду без дробного Коми).
А чем сам гитхаб не устраивает? Lean - это тоже текстовый язык, и он отлично интегрируется в Git и GitHub.