Использовать базу данных для искусственного интеллекта?

Question

Я работаю над проблемой с игрушкой: она делает код, который учится быть непобедимым на Tic Tac Toe, только играя сам.Я новичок в такого рода вещах ... Я просто решил, что сделаю это, используя генератор случайных чисел, чтобы выбрать ходы для X и для 0 ... и затем вести запись в текстовом файле ходов, который долженникогда не воспроизводиться снова (в этой части алгоритма есть некоторая сложность, но не берите в голову).

Мой вопрос: должен ли я использовать систему управления реляционной базой данных вместо текстового файла для хранения «состояний игры»избежать?Я испытываю желание сделать это, потому что тогда я мог бы иметь уникальные идентификаторы для каждого игрового состояния ... и специальные таблицы, добавленные в базу данных, чтобы отслеживать, скажем, все "игровые состояния", которые предшествовали потере "игрового состояния" (например, одно «игровое состояние», сопоставленное с множеством «игровых состояний предыдущего хода».Мне кажется, что при некотором умном использовании таблиц система управления реляционными базами данных будет намного проще, чем грубый текстовый файл.Я предполагаю, что недостатком будет время выполнения, необходимое для самообучения кода (потому что все обращения к базе данных могут занять некоторое время).

Любая мудрость будет высоко оценена.Разумно ли думать об использовании базы данных?Точный ли мой анализ плюсов и минусов?Спасибо!

Answer 1

Tic Tac Toe имеет 9 полей.

в любом поле у ​​вас есть 3 варианта значения ('', 'X', 'O').Это делает 3 ^ 9 = 19,683 возможных комбинаций.

Вам необходимо хранить 9 бит для любого поля (0,1 или ноль).Это составляет 177,147 бит данных, не говоря уже о метаданных.

Кроме того, не все возможные комбинации действительны (у вас не может быть 3 O и только 1 X в вашем поле).Это делает приведенное выше число еще меньше.

Другими словами, если у вас нет чрезвычайно высоких временных ограничений, выбор вашей базы данных не зависит от производительности.

Вам все равно следует прочитать об индексации, если вы используете реляционные базы данных.

Однако я бы не рекомендовал вам хранить ваши данные в текстовых файлах (не говоря о d-no-sql db, а о реальных текстовых файлах).на вашем жестком диске).Потому что это делает доступ сложным и, если не запрограммированным, может быть медленным.

Последним рекомендацией будет система реляционных баз данных, потому что здесь у вас есть больше ограничений, таких как уникальные идентификаторы и отсутствие нежелательных типов данных.Это часто приводит к меньшему количеству ошибок / ошибок.Кроме того, вы можете дать любой возможной комбинации уникальный ключ и позволить вашей СУБД применять его для вас с помощью unique_constraint.Затем вы создадите «таблицу связей», которая связывает только идентификаторы ваших уникальных комбинаций.

Answer 2

Флориан хорошо начал, но учтите, что у вас заметно меньше, чем 3 ^ 9 игровых состояний.Если мы предположим, что X движется первым, то число X записей должно быть равно или на единицу больше, чем количество O записей.Например, доска XX- | --- | --- недопустима.

Есть 7665 уникальных позиций доски .Это должно быть достаточно мало, чтобы дать каждому простой ключ (например, его целочисленное значение в трине).Используйте пакет graph для построения графика позиций, которые ведут к другим позициям;пометить края с выбором хода.Например, если мы закодируем плату как 0 = пусто, 1 = X, 2 = O, тогда мы получим открывающую доску (0), переходящую в позицию 1 (или 000 000 001) по выбору 9 (нижний правый угол).

Вы должны иметь возможность хранить все игровое дерево сразу в памяти: 7665 узлов со средним числом, возможно, 6 ребер на узел, 3 слова на ребро.Это ~ 120 тыс. Слов памяти для всего дерева, за до вы применяете обрезку во время тренировки ИИ игры.

Answer 3

RDB (реляционные базы данных) полезны, когда вы должны быть уверены, что все данные согласованы, однако скорость системы (из-за транзакций, блокировки и т. Д.) Менее эффективна, чем база данных объектов (Redis)или База данных документов (MongoDB)

Вы можете использовать этот подход с MongoDB:

• 1 игра представляет собой документ JSON, который содержит:

  идентификаторgame (например, «0001»)

  Состояние игры (например, «0» для «0», «1» для «X», «2» в противном случае

  Массив, содержащий все ходы)во время игры

  Другие данные, такие как время, дата, ...

После этого вы можете просто исследовать все JSON с помощью регулярного выражения в Mongo Connector.

Мне очень нравится ваш анализ проблемы с базой данных, это правда!

Надеюсь, это может быть полезно.