Комментарии 7
Сам являюсь разработчиком пет-проекта по решениям теории игр на Ruby. Есть ряд вопросов к требованиям:
- пункт 7 говорит о работе с базой для вычисления стратегий и игр, что недостаточно обоснованно, пользователь вносит данные и просит отчет. Сами отчеты можно сохранять в базу - с данными результатами прогона. Зачем хранить промежуточные данные для расчетов, неясно, к тому же, с факториальной сложностью? Это может периодически класть базу.
- 12 и 13 пункты явно нуждается в ограничении числа стратегий и игроков. Например, вычисление биномиальных коэффициентов Вектора Шепли невозможно для более, чем 171 игрока ввиду получения крайне малых для обработки чисел. Лучшей стратегий здесь была бы такая же проверка каждого решения на адекватную скорость и возможность получить решение в принципе.
- по 14 пункту не понятно какой принцип оптимальности имеется ввиду - выбор в теории игр более чем огромен.
- 16 пункт опять же крайне сложно реализовать, даже есть иметь ввиду что раундов будет меньше 1000 и игроков меньше 500.
Интересен подход с характеристиками и созданиями отдельного класса для каждого игрока. Я рассматривал только одну характеристику - выигрыш (вне бизнес-логики или обоснования), что позволило требовать от пользователей hash с регистро-независимыми уникальными ключами как названию коалиции: {a: 1, b: 2, ab:3}. В том числе для одноэлементных коалиций. Но в вашей реализации эти характеристики можно использовать в том числе для раздела "игр на сетях" - в зависимости от данной связи объектов, описанных через их атрибуты, что очень интересно. Хотелось бы увидеть продолжение проекта.
Спасибо, буду думать в сторону решения проблемы возрастания сложности. Пока вижу только вариант "в лоб" - сыграть множество игр (варьируя количество, характеристик игроков, их стратегии) и собирать статистику.
Хранить в базе данных предполагаю все созданные экземпляры всех классов (объединяя их в группы и сетевые структуры), а не только те, которые были сыграны - просто для удобства и возможности командной работы над задачей.
О выборе оптимального решения - здесь должна быть модель, позволяющая каждому игроку добиваться максимизации своей функции. Одному, к примеру, важны сроки проекта, при условии, что проект выйдет хотя бы в 0, другому интересна максимальная прибыль по отношению к вложенным средствам, третьему - максимальная выручка и доля рынка...
Максимизация функции полезности через варьирование параметров - тогда может помочь уже готовое решение - симплекс-метод. На питоне есть имплементации. Тогда задачка упрощается и нужно только написать теоретико-игровую оболочку. Однако тут нужно все-таки знать о какой теоретико-игровой модели речь. Я писал на питоне в магистратуре поиск равновесия по Нэшу в ромбовидной иерархической структуре и там для получения решения для 4 игроков (управляющий центр, два игрока по середине ромба и самый нижний игрок (в ромбе)) мне приходилось решать методом Монте-Карло, генерируя десятки и сотни тысяч случайных векторов для нескольких сотен решений ЗЛП симплекс-методом. Если интересно - https://dspace.spbu.ru/handle/11701/32556
Поэтому сначала лучше рассмотреть небольшой размер задачи вашей модели и посмотреть как получится найти решение для нее.
Спасибо, буду думать в сторону решения проблемы возрастания сложности. Пока вижу только вариант "в лоб" - сыграть множество игр (варьируя количество, характеристик игроков, их стратегии) и собирать статистику.
Хранить в базе данных предполагаю все созданные экземпляры всех классов (объединяя их в группы и сетевые структуры), а не только те, которые были сыграны - просто для удобства и возможности командной работы над задачей.
О выборе оптимального решения - здесь должна быть модель, позволяющая каждому игроку добиваться максимизации своей функции. Одному, к примеру, важны сроки проекта, при условии, что проект выйдет хотя бы в 0, другому интересна максимальная прибыль по отношению к вложенным средствам, третьему - максимальная выручка и доля рынка...
Шизофази́я (от др.-греч. σχίζω «расщеплять, раскалывать» и φάσις «речь, высказывание») — симптом психических расстройств, выражающийся в речевой разорванности — нарушении структуры речи, при которой, в отличие от речевой бессвязности (потока несвязанных слов), фразы строятся правильно[1], однако не несут никакой смысловой нагрузки, а содержание речи соответствует содержанию бреда[2].
Функциональные требования: код должен быть открытый, должны быть понятны связи между классами, количество игроков от 0 до бесконечности, минимимум два примера использования функции в коде, должна быть дружелюбна к ML - нейронные сети должны распозновать текст.
Абсолютно несвязанные требования к кодстайлу, архитектуре, бизнес-требованиям заканчиваются нелепой попыткой создать метакласс на питоне: это статья - пример шизофазии.
Это функциональные требования, они в большинстве случаев всегда так формулируются, как набор плохо взаимосвязанных "хотелок".
Сделать их взаимоувязанными, да еще и "урезать" с учетом всех возможных ограничений - это уже следующие этапы.
Поскольку я себе в этом проекте и заказчик, и исполнитель, я фактически играю в игру, где выигрышем являются интересно проведенное время, полученный опыт и потенциальная радость, если на выходе получится что-то корректно работающее (но есть вероятность, что не получится, то есть результат не удовлетворит ни меня, ни стороннего наблюдателя, который в теме).
Создаем библиотеку по теории игр на питоне для максимально широкого спектра разнообразных игр