Хм... Лес предложил этот топологический ракурс несколько недель назад . Я думал , что это общее место всех Го программ . А как иначе ? Неужели для каждого пробного хода заново определять все объекты и границы ? А связанные списки объектов , границ и точек - это и есть топологическое представление , разве нет ?



Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

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

--- Хм... Лес предложил этот топологический ракурс несколько недель назад ----
Но в том варианте как сейчас.....

-- Не все так прекрасно. Такое представление дороже матричного, ---

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

--- о выгоде можно будет говорить, когда будет формальная процедура извлечения информации, использующая помянутые особенности. ---

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

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

Лес , что значит матричное представление ? Связанные списки , определяющие топологию , можно прекрасно реализовать прямо на матрице . Это кажется ВинниПух упомянул на форуме .

По-моему "формальная процедура" использования таких списков есть во всех существующих Го программах , играющих и служебных .

Ну представьте себе движок гобана или SGF парсера . Как учесть очередной ход без этих списков ? Проверить наличие своих и чужих соседей , проследить их границы (!!!) и только после этого решать , разрешен ли ход и съедается ли что-нибудь . Как мурашки - бегают ?

И сравни с представлением в духе ВинниПуха . Хранятся списки , при каждом камне - десяток линков на продолжения списков , число линков абсолютно статично . Каждый ход требует анализа локальной ситуации и учета изменений в списках . И больше ничего . Проход по списку - только при съедении объекта [еще при слиянии объектов] , да и не заливка ведь . Этот путь не просто лучше , он практически единственный .



Отправка отредактированного (19/11/03 18:41)

Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

Кажется это упомянул не ВинниПух, а я. :)) Такой уж у меня парадоксальный характер.
Я действительно использую это дело в своем SGFView. Одна из проблем - я просчитал один вариант, надо переходить к другому. Значит надо сделать откат к развилке. Надо восстановить доску + служебную информацию. Делая это сохранением/восстановлением массива, получаем С х N x N. N-размер доски, С-количество полей на один пункт. Если доска 19х19, то без служебной информации имеем 361 единицу хранения, со служебной - 1083. Для ActionScript-а в копировании такого массива приятного мало.

Лес , прости великодушно за путаницу в авторстве !

Хм... Сохранять копию позиции в каждой развилке ?

Я бы просто запоминал , какие камни когда удалил . И при движении туда-сюда вдоль линейного варианта мне бы хватило этой инфы и одной копии доски . А если от развилки идешь в другом направлении - ну тогда ставишь камни как новые .

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



Наш рот всегда открыт для диалога (c) Владимир ВишневскийOkruzhor (экс-Игозавр)

>>Я бы просто запоминал , какие камни когда удалил .

Я же храню информацию о том, к какой цепи принадлежит камень. В процессе две группы могли слиться, расцепить при откате их не так просто.

Впрочем, нечто подобное я планирую, но на потом.