Валерий дмитриевич! Я двумя руками ЗА!
Нам бы кусок хлеба и компьютер........

Проще Динерштейна раскачать на такой кредит. Тем более что он обещался помогать в данном проекте.



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

Пардон, вопросы есть.

1. Какая выбрана основная парадигма - ООП или алгоритмическое.
2. Если ООП то нужна объектная модель Игры - есть ли готовые.

ИМХО и ООП не потянет Го. Желательно что-то вроде системы знаний,
и свой язык разработать. Слышно было, что разработчики MFGO так
делали, но это не проверено.

>> Лес! Что имелось ввиду -
надо уточнить принципы классификации ---

Для начала, определить объекты классификации. Группы? Поскольку разбиение позиции на группы уже задача нетривиальная, надо использовать более простое понятие. Цепи? Цепь сама по себе, в отрыве от контекста несет очень мало информации.
Будет ли это чем-то, как бы вырезанным из доски ножницами, или будет какая-то предварительная обработка позиции?

Во-вторых, принципы группировки объектов в классы.

В-третьих, техническая реализация 1-го и 2-го.

Пункт три имеет смысл только после уточнения первых двух, но и наоборот, модель должна предполагать возможность эффективной реализации.
Короче, до определенности пока далеко.

>> Слышно было, что разработчики MFGO так делали, но это не проверено.

РазработчиК. Он один, без ансамбля. ;)

Какие множества объектов будут рассматриваться? Если подмножества множества камней в фиксированной позиции - это одно. Если множества групп камней, возникающих в вероятных будущих позициях из данной формы - это другое. Да, оценка фиксированной позиции - конечная цель в любом переборе или эвристическом алгоритме. Но без определения понятия группы и ее статуса не обойтись. Понятие связности (не в топорлогическом смысле, а в го-игровом, т.е. как некоторую характеристику возможности разделения на части в процессе игры). Интересные обсуждения на эту тему есть, кажется, на сайте Sensei's Library. В общем, проблемы есть, без их решения мало что сдвинется. Но и идеи тоже есть.



Отправка отредактированного (09/01/04 15:55)

Смотри в корень

Олег!
Я рад, что согласен. Я даю данные на вход и на выходе должен быть требуемый результат. Что внутри- это твои проблемы. Нужен тесный контакт. Я должен знать, что ты можешь сделать, а что нет. Будем строить дом из кирпичиков. Чем больше независимых кирпичиков, тем универсальней будет программа. Я определяю идею каждого кирпичика и взаимосвязи между ними, а ты сам реализуешь нутро кирпича. Повторяю, только в тесном общении с друг другом.
С уважением

Валерий Дмитриевич!
В воскресение будете во дворце?
тел. надеюсь у Вас тот же..... мой дом 577814 (утром до 9-30 вечером после 22-30)


LES'у
-- В-третьих, техническая реализация 1-го и 2-го. --
с этим справиться можно.....

Классификация.......... и группировка - пока далековато.
В начале думаю построить определения явно связанных камней.

Т.Е. *-*-*-* явно связаны , а
эти *-- * не явно, но они имеют хорошую позицию, так как
*
представляют из себя базисный треугольник ( надежную форму).... и т.д. Вот теперь как это понятие применить к системе программирования? (По типу - пункты одного цвета считаются явно связанными, если лежат на одной прямой и если между ними нет точек перехода {т.е. точек разрыва}). Как дать более точное и однозначно трактуемое определение?

Все таки, возвращаемся на круги своя - к истоку - дать элементарные, однозначные определения. Тот базис из которого строиться игра, ту основу, на которой она лежит. И нужно не забывать - что уровень нынешнего железа строиться по логическому принципу - да -нет (0,1)
третьего - у него нет.
Если вводить свои критерии логики на четыре уровня - да, нет, не знаю, может быть. то нужно, как правильно задал вопрос Кирилл, вводить свой собственный язык формализации. И он будет строиться на объектных критериях определений, которые в свою очередь, будут состоять из элементарных "позиций".
И этот язык, должен быть понятен и -"кухарке".....)))



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

Олег!
У меня тел. тотже 955439. В воскресенье буду в клубе с 11 до 14-15 час.
С уважением

jотлично! Я подойду.



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

Предлагаю обсудить другую модель.
Кол-во объектов игры определено размерами доски.
Каждый объект описывается параметрически.
Ход - изменение параметров объектов.
Параметры делятся на три группы:
1. Обязательные (задаваемые правилами игры),
2. Временные (введенные человеком для описания техники и стратегии игры),
3. Выявленные (появляющиеся на этапе обучения и (или) самообучения программы.

Так получилось, что очень схожая позиция изложена мной в другой ветке - Разбиение...

Базисный объект - группа (не формализуем пока).
Свойства объектов изменяются при ходе (или ход заключается в изменении свойств - суть не меняется). У Сергея Межова соответствующее понятие называется параметром. Проще свойство, как в объектно-ориентированных языках. Это более общее, универсальное понятие. свойства могут быть совершенно разнородными. Параметры предполагаюся неявно имеющими численную природу, свойство может ветвиться по своей внутренней структуре дальше:

Объект. свойство. свойствосвойства. ...



Отправка отредактированного (10/01/04 12:19)

Смотри в корень

А может чуть по другому определить? если устроит.

1. Базис - пунк игрового поля, занятый или не занятый камнем игрока.
2. Объект - камень игрока (свой или чужой).
3. Свойства объекта - :
а. координаты расположения
б. цвет камня
в. количество дамэ (нулевой базис)
г. линия расположения от края игрового поля
д. количество базиса до другого объекта
е. направление базиса ( положительный - до своего объекта, отрицательный до чужого объекта)
ж. нуль-первый базис - пунк дамэ занятый своим камнем (объектом)
4. Связка - объекты имеющие нуль-первый базис.
5. Первичная группа - связки имеющие переход в пределах одного базиса.
6. Вторичная группа - связки имеющие переход в пределах двух базисов.



Ну что это за Жизнь... без примеси сумасшествия совсем не интересно......
[www2.psy.uq.edu.au]
[www.mercury.csse.unimelb.edu.au] - Крутой Меркурий
[habrahabr.ru]
[shogi.by] - Shuogi

В теме Разбиение... произошло примерно тоже: подмена методологических проблем алгоритмическими. Но в конце концов там обсуждение вышло на базисные понятия, каковым является, например, влияние.

Мое мнение - надо определиться с базисными понятиями. Камень - не базисное понятие, это элемент инвентаря. Состояние пункта доски - это как ячейка памяти в ЭВМ, тоже базисным элементом в методологическом плане выступать не может, это элементарный структурный элемент, "атом" и только.

Базисным понятием я считаю группу ("молекула"): подмножество пунктов доски, находящихся в определенных синхронных состояних (описательно: занятых камнями одного цвета) и выделяемое с помощью задания определяющих свойств (какие - следующий методически этап, все равно потом выясним). Тогда следующим базисным понятием следует считать влияние групп камней.

В теме Разбиение... пытались пренебречь этим подходом, сразу переходя на алгоритмическое структурирование. Тогда появилась неоднородность в связи с зависимостью алгоритмов от стадийности. Вот в чем вопрос: если правильно сформулированы ключевые понятия и выбраны оценки, то стадийность вытекает из них, аналогично переходу количества в качество, а не задается внешним образом.

Кто и как будет определять, что вот до этого хода - фусэки и применяем такой-то алгоритм, а затем - тюбан, для которого и алгоритм, соответственно, другой? Это тупиковый путь. Влияние групп камней есть на всех стадиях.

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

Влияние должно определяться так, чтобы оно было однородно в смысле стадийности. Т.е. одно и тоже определение (формальное) влияния в фусэки работает на распределение сфер влияния, в тюбане - на воздействие при атаке и защите групп, в йосэ - на соотношения сэнтэ-готэ и пр., и в конечном итоге - трансформируется в очки результата.

Как влияние может быть универсально и в смысле глазообразования и, значит, формирования территории? Определенный уровень влияния групп черных или белых означает контроль над территорией (и, значит, превращения зон влияния в глаза). Топологическая классификация внутренних областей групп (обобщенных глаз) должна позволять определять формы, способные к образованию двух глаз, и это может также выражаться значением некоторого численного параметра.

Итак, от универсальных понятий - к численным параметрам, их характеризующим, а затем - к алгоритму. Таков, мне кажется, методически правильный путь.



Смотри в корень

У меня другое мнение.
И сегодня процесс начался.
С уважением

В чем заключается оценка позиции?

Возможно, в моделировании ее в рамках некоторых базовых понятий, о чем многие говорили.

Одним из основных таких понятий является группа камней. Но выделение групп камней в позиции неоднозначно. Однозначно определяются только цепочки (непосредственно контактирующие камни).

Идея заключается в том, чтобы не пытаться провести единственное выделение групп камней, а рассматривать альтернативные варианты. Т.е. минимакс можно применять не только для расчета вариантов ходов, то и вариантов декомпозиции.

Кончно, и структура алгоритма почти не затрагивается...



Смотри в корень