KataGo может играть на среднем железе, причем играет на уровне средних топов только лишь на одних предсказаниях нейросети (это вообще без использования перебора с помощью Монте-Карло). Что касается обучения - в описании написано следующее:
If tuned well, a training run using only a single top-end consumer GPU could possibly train a bot from scratch to superhuman strength within a few months.
Но по идее последняя версия gpt-4o может "думать", итеративно отвечать на вопрос. Но не понятно, можно ли использовать это свойство для перебора позиций, типа симуляции Monte Carlo tree search.
Другие, но есть много общего, все-таки это родственные игры. Есть обстоятельства, которые облегчают: отсутсвие Ко, а есть те, которые осложняют: в точках обычно строятся цепи намного длинней.
В целом KataGO действительно можно попробовать адаптировать под Точки, с учетом того, что это самообучающаяся нейросеть. Из этого может получиться что-то толковое.
Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд.
Это не элементарный перебор, потому что дерево растёт экспоненциально - нужно быстро и хорошо выбирать нужные ходы на каждом шаге. Особенно это актуально для таких игр как Го, в которых ИИ значительно продвинулся именно благодаря нейросетями. И стокфиш после этого тоже продвинулся.
Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии.
Партии до конца не просчитаны в шахматах и скорей всего не будут - количество комбинаций слишком огромное. Подтянулись не только количественные изменения, но и качественные.
Мне нравится пример из мира шахмат: компьютерные программы постепенно побеждали лучших шахматистов мира. Но если взять в одну команду лучшего шахматиста и компьютер, то с таким тандемом справится или играть на равных практически не реально.
А мне не нравится этот пример. Современные программы и так побеждают любых шахматистов и без помощи ассистента. Т.е. человек тут скорей мешает, чем помогает. С натяжкой подходит игра Го (Бадук), потому что там намного больше комбинаций, и она более абстрактная.
Скорей всего существуют - надо же было кому-то охранять пещеру, когда все остальные спят. Да и много других животных, которые ведут ночной образ жизни.
Скорей это просто неудобно, т.к. при этом полностью блокируется рабочий аккаунт, который потом восстанавливается не полностью корректно. Ну и РФ, разумеется, работать нельзя. Но чтобы настоятельно не рекомендовали - нет такого.
В том-то и дело, что компилятор может, а Вы почему-то нет.
Так если компилятор может, значит это формально правильно. И складывается впечатление, что это у вас недостаточное понимание предмета обсуждения.
Если есть ограничение: можно читать, но нельзя писать, как Вы их собираетесь туда записывать? Например, в списке есть 2 арбуза, как Вы собираетесь туда записывать 3 апельсина? А ведь это и нужно сделать по идее, если Вы их хотите суммировать.
Я не собираюсь туда записыват - я получаю read-only коллекцию в виде объектов, а дальше если в коде будет вызов метода записи, то код просто не скомпилится:
val oranges = listOf<Orange>(Orange(), Orange())
val objects: List<Any> = oranges
objects.add(Watermelon()) // Compilation error
То же самое, если суммировать две коллекции из разных объектов.
Никакой List<Any> в Яве невозможен. Возможен List<String> или List<Integer>, что вполне логично: разные типы не должны смешиваться.
К вашему сведению, выше написан код на Kotlin, там такое можно. В Java List не является read-only, а значит там написать такое нельзя и система типов в Java более ограниченная. Но можно сделать так:
import java.util.ArrayList;
import java.util.List;
public class Test {
class Watermelon {}
class Orange {}
void test() {
List<Object> objects = new ArrayList<>();
objects.add(new Watermelon());
objects.add(new Orange());
}
}
Гипероператоры - это вполне конкретные математические действия над числами. Действие гипероператора можно показать на практике с предметами, так почему Вы считаете, что он не имеет связи с реальностью?
То же самое можно сказать про объекты - это конктреные действия над типами. Логика такая: при сложении коллекций разных типов дженерик аргумент реузьтирующей коллекции будет иметь наиболее общий тип, и она будет только для чтения.
В реальной жизни нет применения пентации и гипероператоров более высокой степени. А числа - это тоже абстрация, как и объекты.
Разница большая. Мы здесь общаемся на русском языке, поэтому применять более примитивный английский язык по меньшей мере странно. В английском языке fruit имеет значения фрукт, плод, результат, ягода. Это свидетельствует только о том, что большинство англичан не понимают, чем различаются фрукт, плод и ягода, а у нас это в базовой школе проходят. И откуда знать читателям, какое из этих значений Вы имели в виду? Вы бы ещё на арабском написали...
Потому что английский - это стандарт для международного общения, на нем больше всего инфы почти обо всем и почти все языки программирования основаны на нем. Общаемся на русском, а код - на английском. Арабский тут вообще не тему - из распространенного на нем только арабские цифры.
Самое главное, Вы забыли рассказать, с какой целью Вы их суммировали? ;)
Специально для невнимательных цитирую себя же:
Практичное реальное применение конкретной задачи с объектами выше - собратить статистику по всем существующим объектам в текущий момент работы приложения. Это используется при анализе потребления памяти.
Если даже компилятор может вывести типы, то и человек может. Абстратные классы - это уже нереальные объекты, их даже создать нельзя. Стоит их запретить?
Не противоречит он логике системе типов. Во многих языках программирования объект является базовым классов для любых других классов. Т.е. с точки зрения компилятора что Any (любой объект), что Fruit являются базовыми классами для Orange, что для Watermelon. У Fruit может быть чуть больше общих методов и свойств, но и у Any они тоже есть.
Поэтому контейнеры, разрешающие запись, желательно делать инвариантными.
Ну вы опять не разобрались в ситуации детально и что-то процитировали. В коде выше:
val objects = oranges + watermelons
Результирующая коллекция objects является read-only списком, т.е. она не разрешает запись, но разрешает чтение. Здесь нет никакого противоречия.
Можно даже упростить до такого:
val objects: List<Any> = oranges
И будет objects из которого можно читать объекты, но в него нельзя писать, иначе можно поломать типы.
Какую связь с реальностью имееют дробные производные или гипероператор? В математике вообще ничего нельзя пощупать. Практичное реальное применение конкретной задачи - с объектами выше - собратить статистику по всем существующим объектам в текущий момент работы приложения. Это используется при анализе потребления памяти.
Какая разница что в русском они не являются синонимами? Я писал код на английском, с английскими комментами, а там fruit может обозначать и фрукт и плод. Главное, что и апельсин и арбуз можно назвать плодом - это абстракция.
Вы думали, что я не замечу, что у Вас в коде есть переменная fruits? Т.е. фрукты? Это ведь значит, что по факту Вы суммируете не апельсины и арбузы, а фрукты ;)
Ок, так сойдет?
class Orange
class Watermelon
val oranges = listOf(Orange(), Orange())
val watermelons = listOf(Watermelon(), Watermelon(), Watermelon())
fun main() {
// Compiler infers the most common type that is `Any` (object)
val objects = oranges + watermelons
}
Если что - такое сложение позволяет сделать такая возможность, как ковариантность типов. В данном случае не важно, что суммируется: плоды или объекты, потому что с точки зрения компилятора суммируются коллекции разных типов. Причем выше в комментариях я специально написал такое:// But actually it's possible to concatenate objects of any type.
В языках программирования логика есть. А вот в головах некоторых программистов её нету, поэтому они в состоянии написать абсолютно бредовый код, который даже будет работать, только не будет иметь никакой связи с реальностью.
Во-первых, как выше уже писал, ковариантность (и контрвариантность) - это важное понятие в языках программирования, которое позволяет сделать код более обобщенным и без лишнего дублирования. Во-вторых, а вы знаете, что в математике куча теорий, которые не имеют связи с реальностью, например, дробные производные, да и комплексные числа - это абстрактное понятие. У математиков тоже логики нет, и они придумывают что-то не связанное с реальностью?
Ну, и к Вашему сведению, арбуз не фрукт, а ложная ягода или плод, поэтому Ваш код тоже бредовый с точки зрения реальности. И язык программирования тут абсолютно не при чём. Назовите переменную как-то по-другому
Я в курсе, но в данном случае это не важно. К тому же если вы попытаетесь перевести слово "плод", то один из вариантов переводов будет "fruit". Т.е. это у вас бредовое утверждение, без углубления в вопрос.
А вот вопрос "сколько будет, если сложить 3 апельсина и 2 арбуза" глупый, потому что не логичный.
Логичный, вот вам пример сложения 3 апельсинов и 2 арбузов например на языке Котлин:
abstract class Fruit(val color: String)
class Orange : Fruit("Orange")
class Watermelon : Fruit("Green")
val oranges = listOf(Orange(), Orange(), Orange())
val watermelons = listOf(Watermelon(), Watermelon())
fun main() {
// Kotlin infers the most common type that is `List<Fruit>`
// But actually it's possible to concatenate objects of any type
val fruits = oranges + watermelons
// Now we can use common features like `color`
fruits.forEach { println(it.color) }
// And prints the size
println(fruits.size) // Prints `5`
}
Т.е. ответ: "5 плодов" или хотя бы "5 объектов" - абсолютно логичный. Или по вашему в языках программирования нет логики?
И это не глупый вопрос, поскольку для требуется использовать такую операцию как сложение, которая может определяться по-разному, и понимание типов. Т.е. для этого применимо то же самое, что и для вопроса "может ли Земля вращаться вокруг Солнца", а именно: "логично представить все возможные варианты и просчитать, насколько они соответствуют реальности".
Вроде я уже когда-то давно читал о такой змейке.
Интересно, что у них самый большой субпиксель используется для синего цвета. Это обуславливается как-то через восприятие цвета?
Почему не на Avalonia?
KataGo может играть на среднем железе, причем играет на уровне средних топов только лишь на одних предсказаниях нейросети (это вообще без использования перебора с помощью Монте-Карло). Что касается обучения - в описании написано следующее:
Это выглядит подъемно.
Ветряки тоже немного ветер замедляют
Но по идее последняя версия gpt-4o может "думать", итеративно отвечать на вопрос. Но не понятно, можно ли использовать это свойство для перебора позиций, типа симуляции Monte Carlo tree search.
Другие, но есть много общего, все-таки это родственные игры. Есть обстоятельства, которые облегчают: отсутсвие Ко, а есть те, которые осложняют: в точках обычно строятся цепи намного длинней.
В целом KataGO действительно можно попробовать адаптировать под Точки, с учетом того, что это самообучающаяся нейросеть. Из этого может получиться что-то толковое.
Из байткода можно практически полностью восстановить исходник, по-умолчанию все имена переменных там сохраняются.
Субъективные и стереотипные пункты: разные айтишник бывают.
Это не элементарный перебор, потому что дерево растёт экспоненциально - нужно быстро и хорошо выбирать нужные ходы на каждом шаге. Особенно это актуально для таких игр как Го, в которых ИИ значительно продвинулся именно благодаря нейросетями. И стокфиш после этого тоже продвинулся.
Партии до конца не просчитаны в шахматах и скорей всего не будут - количество комбинаций слишком огромное. Подтянулись не только количественные изменения, но и качественные.
А мне не нравится этот пример. Современные программы и так побеждают любых шахматистов и без помощи ассистента. Т.е. человек тут скорей мешает, чем помогает. С натяжкой подходит игра Го (Бадук), потому что там намного больше комбинаций, и она более абстрактная.
Это только гипотеза, экспериментально излучение Хокинга не подтверждено, т.к. все обнаруженные черные дыры очень большие.
Скорей всего существуют - надо же было кому-то охранять пещеру, когда все остальные спят. Да и много других животных, которые ведут ночной образ жизни.
Скорей это просто неудобно, т.к. при этом полностью блокируется рабочий аккаунт, который потом восстанавливается не полностью корректно. Ну и РФ, разумеется, работать нельзя. Но чтобы настоятельно не рекомендовали - нет такого.
Ну это просто пользовательская issue, в реальности такого конечно не произойдет :)
Забавно, что кто-то даже заводил такую issue: https://youtrack.jetbrains.com/issue/KT-71605/Rename-Kotlin-to-something-else-to-distance-from-Russia
Так если компилятор может, значит это формально правильно. И складывается впечатление, что это у вас недостаточное понимание предмета обсуждения.
Я не собираюсь туда записыват - я получаю read-only коллекцию в виде объектов, а дальше если в коде будет вызов метода записи, то код просто не скомпилится:
То же самое, если суммировать две коллекции из разных объектов.
К вашему сведению, выше написан код на Kotlin, там такое можно. В Java
Listне является read-only, а значит там написать такое нельзя и система типов в Java более ограниченная. Но можно сделать так:То же самое можно сказать про объекты - это конктреные действия над типами. Логика такая: при сложении коллекций разных типов дженерик аргумент реузьтирующей коллекции будет иметь наиболее общий тип, и она будет только для чтения.
В реальной жизни нет применения пентации и гипероператоров более высокой степени. А числа - это тоже абстрация, как и объекты.
Потому что английский - это стандарт для международного общения, на нем больше всего инфы почти обо всем и почти все языки программирования основаны на нем. Общаемся на русском, а код - на английском. Арабский тут вообще не тему - из распространенного на нем только арабские цифры.
Специально для невнимательных цитирую себя же:
Если даже компилятор может вывести типы, то и человек может. Абстратные классы - это уже нереальные объекты, их даже создать нельзя. Стоит их запретить?
Не противоречит он логике системе типов. Во многих языках программирования объект является базовым классов для любых других классов. Т.е. с точки зрения компилятора что
Any(любой объект), чтоFruitявляются базовыми классами дляOrange, что дляWatermelon. УFruitможет быть чуть больше общих методов и свойств, но и уAnyони тоже есть.Ну вы опять не разобрались в ситуации детально и что-то процитировали. В коде выше:
Результирующая коллекция
objectsявляется read-only списком, т.е. она не разрешает запись, но разрешает чтение. Здесь нет никакого противоречия.Можно даже упростить до такого:
И будет
objectsиз которого можно читать объекты, но в него нельзя писать, иначе можно поломать типы.Какую связь с реальностью имееют дробные производные или гипероператор? В математике вообще ничего нельзя пощупать. Практичное реальное применение конкретной задачи - с объектами выше - собратить статистику по всем существующим объектам в текущий момент работы приложения. Это используется при анализе потребления памяти.
Какая разница что в русском они не являются синонимами? Я писал код на английском, с английскими комментами, а там fruit может обозначать и фрукт и плод. Главное, что и апельсин и арбуз можно назвать плодом - это абстракция.
Ок, так сойдет?
Если что - такое сложение позволяет сделать такая возможность, как ковариантность типов. В данном случае не важно, что суммируется: плоды или объекты, потому что с точки зрения компилятора суммируются коллекции разных типов. Причем выше в комментариях я специально написал такое:
// But actually it's possible to concatenate objects of any type.Во-первых, как выше уже писал, ковариантность (и контрвариантность) - это важное понятие в языках программирования, которое позволяет сделать код более обобщенным и без лишнего дублирования. Во-вторых, а вы знаете, что в математике куча теорий, которые не имеют связи с реальностью, например, дробные производные, да и комплексные числа - это абстрактное понятие. У математиков тоже логики нет, и они придумывают что-то не связанное с реальностью?
Я в курсе, но в данном случае это не важно. К тому же если вы попытаетесь перевести слово "плод", то один из вариантов переводов будет "fruit". Т.е. это у вас бредовое утверждение, без углубления в вопрос.
Логичный, вот вам пример сложения 3 апельсинов и 2 арбузов например на языке Котлин:
Т.е. ответ: "5 плодов" или хотя бы "5 объектов" - абсолютно логичный. Или по вашему в языках программирования нет логики?
И это не глупый вопрос, поскольку для требуется использовать такую операцию как сложение, которая может определяться по-разному, и понимание типов. Т.е. для этого применимо то же самое, что и для вопроса "может ли Земля вращаться вокруг Солнца", а именно: "логично представить все возможные варианты и просчитать, насколько они соответствуют реальности".