Ifrit
Часть 8
 

Опубликованная версия Ifrit_j3_4

_______________________________________________________________________________________________

Суббота, 17 июля 2010 г.

Следующей версии не будет, если она не станет сильнее. Как же мне ее усиливать?

1. Это оценка. Совершенно непонятно насколько она адекватна.

2. Это поиск. Нет ли в нем ошибок, которые серьезно срезают силу игры?

3. Возможно, что этот набор эвристик не может давать лучший результат и следует добавлять новые.

Первое время я думал, что дело в скорости перебора. Скорость конечно очень важна, но тут дело не только в ней.

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

Потом я думал, что дело в ЛМР. Это очень мощная эвристика но, похоже, дело не только в ней.

Возможно, дело в эффективной отсечке по оценке из хеш-таблицы. Либо есть еще, какие-то отсечки, которые я пропустил.

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

Дальше следует сказать о продлениях. У меня только на шахе. Видимо этого мало.

Ну и конечно корневой поиск. Возможно, это именно то место, которое у меня сильно недоработано.

Еще надо выяснить, какое значение имеет продления на шахе в статическом поиске.

А возможно, что у меня везде хуже и эффект суммируется приводя к катастрофе.

_______________________________________________________________________________________________

Четверг, 22 июля 2010 г.

Все попытки усилить программу окончились ничем.

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

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

Снова и снова ловлю себя на мысли, что я не доверяю коду. У меня не получается сделать достаточно протестированную программу. Внутри нет достаточной модульности. Слишком все перемешано.

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

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

Функция должна иметь средства самоконтроля, работающие в тестовом режиме.

Все это прописные истины, но даже их я умудряюсь нарушать! Понятно, что в таком случае не приходится говорить о надежности кода.

Совершенно недопустимо множество строчек, следующих друг за другом и решающих разные задачи. А у меня это встречается повсеместно.

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

_______________________________________________________________________________________________

Суббота, 24 июля 2010 г.

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

Также понял, что в оценке неправильно положение фигуры ценить меньше, чем положение пешки. Это приводит к необеспеченному штурму пешками. Как правило, такой штурм терпит поражение. Оценку надо будет подправить.

Одолевают сомнения по поводу шаха в статическом поиске. Насколько он там нужен? Но прежде чем его туда добавлять, необходимо будет дописать уклонения от шахов, что несколько усложнит программу. Зато это позволит использовать продления на единственном ходе.

Исправил ошибочный ход при отсечке поиска по времени. В блице это очень даже вредная ошибка.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j3_5

_______________________________________________________________________________________________

Четверг, 29 июля 2010 г.

Ста пунктов прибавки, видимо, нет. Впредь не стоит бросаться такими заявлениями. Теперь надо настроить отсечки. Продолжать тестировать и совершенствовать код.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j3_6

_______________________________________________________________________________________________

Четверг, 2 сентября 2010 г.

После выпуска версии 3.6 ничего не делал. Для повышения рейтинга я больше ничего делать не буду. У меня нет цели добиться высокого рейтинга. Рейтинг - это только показатель качества поиска и не более того.

Обдумывал уклонения при шахе. Получается как-то сложно и коряво. Непонятно даже будет ли он быстрее обычного поиска. И даже если признать, что он будет быстрее то насколько? В любом случае разнится только в скорости обработки шахов.

Хотел вернуть сортировку по истории. Но когда начал делать как-то энтузиазм пропал. Мои тесты показывали, что выгоды от моей реализации никакой. Так зачем возвращать бесполезную вещь?

Эти две эвристики только усложняют код. И даже если прирост есть, по-моему, он не стоит той сложности, которая при этом добавляется.

Еще можно добавить шахи в статический поиск. Но тут тоже, по-моему, слишком сложно получается.

Оценка меня тем более не вдохновляет :)

Вот так получается, что пока я ничего не делаю.

_______________________________________________________________________________________________

Вторник, 14 сентября 2010 г.

Все еще ничего не делаю. Причина простоя в том, что я не хочу больше ничего добавлять в код.

Очевидно, что есть много что можно добавить в код, но я не хочу. Есть внутреннее сопротивление. Такое чувство, что при этом код превращается в свалку.

Еще раз скажу. Мне нужен код, который будет хорошо структурирован, хорошо прокомментирован, хорошо протестирован. Он должен быть понятен. А сила игры это не цель, это приятный бонус.

В последней версии в итоге отвлеченности на рейтинг меня сильно переклинило. Так что даже я не смог заниматься кодом дальше.

Сейчас я возвращаюсь на прежний курс. Т.е. буду тестировать и комментировать. :)

_______________________________________________________________________________________________

Воскресенье, 19 сентября 2010 г.

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

Я недоволен кодом. Слишком запутан и плохо протестирован. Это постоянная проблема и пока мне не удалось ее решить. Я должен быть уверен в коде, а этого нет. Код должен быть понятен для любого программиста, а не только того, кто в теме. Этого тоже нет.

_______________________________________________________________________________________________

Суббота, 2 октября 2010 г.

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

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

Сделать код надежным и понятным. В этих словах бездна работы и понимания.

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

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

_______________________________________________________________________________________________

Понедельник, 4 октября 2010 г.

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

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

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

Обдумывание концепций пока ни к чему не приводит.

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

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

_______________________________________________________________________________________________

Вторник, 5 октября 2010 г.

Во многих функциях поиска огромное количество параметров. Так ли они необходимы?

Обдумываю системный подход. Пока безрезультатно.

Вроде код написан аккуратно, а все равно непонятно. Также непонятно, правильно ли он работает или где-то закрались ошибки.

Надо думать, как с этим справиться.

_______________________________________________________________________________________________

Суббота, 9 октября 2010 г.

Третий день экспериментирую с хеш-таблицей. Сначала пытался вернуться к одному ключу и для ходов и для оценки. В итоге все перестало работать. Думаю, главная проблема в том, что разные ключи пытаются поместиться в одну ячейку таблицы. Это происходит потому, что размер таблицы ограничен, и мы колоссальное множество возможных 64 битных чисел пытаемся разместить в маленьком пространстве.

В итоге вернулся к разным ключам для лучших ходов и оценок.

Дальше опять вернулся к одному ключу. Разницы не увидел. Так что оставлю один ключ - так проще. Дальше можно попробовать кластерную запись.

Отключил часть разоринга. По-моему, я два раза делал одно и то же.

_______________________________________________________________________________________________

Воскресенье, 10 октября 2010 г.

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

Для оценок же такая тактика обесценивает сам метод.

Упростил и слегка подправил futility pruning. Очевидно, что моя реализация была избыточна.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j3_7

_______________________________________________________________________________________________

Пятница, 29 октября 2010 г.

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

Конечно, я далек от реализации этих пожеланий. Но постараюсь двигаться в этом направлении.

_______________________________________________________________________________________________

Среда, 3 ноября 2010 г.

Опять вернулся к идеологии. Хочется привести программу к обоснованному виду. Чтобы все ее части были на своем месте и действительно нужны. Кроме того, они должны быть оптимальны, и правильно работать.

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

_______________________________________________________________________________________________

Четверг, 4 ноября 2010 г.

Начнем с самого начала.

Основа программы - это набор данных, с которыми производятся определенные манипуляции.

Для того, что бы программа была понятна, прежде всего, переменные должны иметь осмысленные имена, выражающие их суть.

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

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

Тогда их легко находить, и понятно для чего они нужны.

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

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

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

Я окончательно забросил идею переписать всю программу на ассемблере. А это значит, что я вновь перехожу к классам и отказываюсь от извращения, когда роль классов выполняло пространство имен.

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

Итогом всего вышесказанного будет то, что я попытаюсь привести программу в соответствие с нормой объектно-ориентированного программирования. Надеюсь, что программа станет понятной и тестируемой.

Только сейчас до меня стала доходить красота и гениальность объектно-ориентированного подхода. Я давно знал этот подход, но не понимал его.

_______________________________________________________________________________________________

Суббота, 20 ноября 2010 г.

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

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

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j3_8

_______________________________________________________________________________________________

Воскресенье, 5 декабря 2010 г.

Начал переход на объектную модель. В версии 3.8 сделал классы списка ходов и доски. Что делать дальше пока не знаю. Главный приоритет это тестируемость кода. Т.е. тестируемость всех эвристик. Сосредоточусь на этом. Нужно разбить программу на тестируемые модули и этапы.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j3_9

_______________________________________________________________________________________________

Четверг, 16 декабря 2010 г.

Некоторые вопросы, на которые хочется получить ответ.

Можно ли усилить движок без добавления новых эвристик?

Настоящий уровень - это потолок данной реализации или силу срезают ошибки?

Как разбить программу на изолированные модули?

Как максимально полно ее протестировать?

Как ее оптимизировать?

Нужны объективные критерии, а не мнения.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j4_0

_______________________________________________________________________________________________

Воскресенье, 26 декабря 2010 г.

Заменил все указатели на ссылки. Точнее почти все. Указатель на динамически выделенную память заменить не смог. Он используется в реализации хеш-таблицы. Я просто обложил этот указатель проверками.

Зачем я эта замена? Все-таки ссылки надежнее. Никогда не знаешь, откуда вылезет неадекватный указатель и как он образуется. Так что лучше решить проблему как класс.

Для этого пришлось переписать модули, в которых использовались указатели. Особенно много переделал в модулях обрабатывающих команды в формате протокола UCI.

Сейчас цель не усилить код, а сделать его более надежным и понятным. Сомнительных мест все еще больше, чем хотелось бы.

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

Думаю, что стоит уйти от создания структур и объектов внутри итераций.

Такой модуль как утиль показывает на недостаточную продуманность структуры проекта. Он еще приемлем в структурной программе, но в объектной ему делать нечего. Он ликвидирован.

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

Перепишу статическую оценку. А может быть, просто допишу. Но так я ее не оставлю. В данный момент она неудовлетворительна.

_______________________________________________________________________________________________

Четверг, 30 декабря 2010 г.

Модули должны взаимодействовать друг с другом только через четко определенные интерфейсы. Глобальные переменные неуместны.

Неясно только, что делать с классами. Использовать extern или нет.

_______________________________________________________________________________________________

Пятница, 31 декабря 2010 г.

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

Делать классы полем класса или нет? Или оставить классы глобальными, т.е. всех на одном уровне. Но тогда объекты не должны создаваться внутри функций и все должны быть глобальными.

Все относящееся к определенной эвристики должно находиться в классе этой эвристики. Каждой эвристике должен соответствовать свой класс и свой модуль. Каждый класс должен находиться в отдельном модуле. Названия класса и модуля должны совпадать.

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

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

Что такое класс? Это связанные данные плюс функции обработки этих данных. Связанность данных может быть ассоциативной, а может быть предметной или еще какой-нибудь.

_______________________________________________________________________________________________

Суббота, 1 января 2011 г.

Необходимо следовать принципу один объект – одна задача. Снижение связанности один из главных приоритетов. Главный вопрос, который нужно решить использовать ли глобальные классы.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j4_1

_______________________________________________________________________________________________

Пятница, 7 января 2011 г.

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

Переписать оценку. Возможно, дело не в ней, но все-таки ее нужно довести до ума.

Прокомментировать и протестировать все классы.

Продолжить оптимизацию архитектуры.

Продолжить оптимизацию классов.

_______________________________________________________________________________________________

Суббота, 8 января 2011 г.

Пройдусь по всему коду и наведу порядок. Хочется добавить нового, но дело в том, что старое пока далеко от нужного уровня.

_______________________________________________________________________________________________

Понедельник, 10 января 2011 г.

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

Центральный вопрос, - как тестировать каждую эвристику, - остается без ответа.

Если генератор я смог протестировать, то все остальное крайне ненадежно. Можно сказать больше - я не уверен, что вообще поиск ведется правильно. Что сама идея не устарела.

_______________________________________________________________________________________________

Среда, 12 января 2011 г.

Начал переписывать поиск. Очевидно, что это надо было сделать раньше. Слишком давно я ничего не менял.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j4_2

Опубликованная версия Ifrit_j4_3

_______________________________________________________________________________________________

Понедельник, 7 марта 2011 г.

Необходимо сделать нормальную оценку.

В архитектуре остановился на модели множества глобальных классов. Конечно, это не совсем объектно-ориентированная модель, но тут этого достаточно. Мне кажется, что наследование в данном случае лишне.

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

_______________________________________________________________________________________________

Суббота, 12 марта 2011 г.

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

_______________________________________________________________________________________________

Суббота, 9 апреля 2011 г.

К коду все еще не притрагивался. Пауза начала затягиваться. Пропал интерес. За это время многое забылось и придется вспоминать по-новой.

Адекватного тестирования создать не удалось.

_______________________________________________________________________________________________

Суббота, 30 апреля 2011 г.

Код не открывал. Февраль, март, апрель. Три месяца ничего не делал в шахматном программировании. Заглох я на оценке. А сейчас даже грузиться неохота.

_______________________________________________________________________________________________

Суббота, 30 июля 2011 г.

Интересно получилось, что пишу опять 30-го. И уже четвертую субботу подряд!

Переустановил операционную систему и теперь опять перешел на 8 студию, потому что по 10 бете кончился ключ. С последней записи программой не занимался.

Февраль, март, апрель, май, июнь, июль ничего не делал! Слишком грузят на работе. Сил на программу уже не остается.

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

Так как застой очевиден, то решил сделать описание программы. В нем изложу все, что я на сегодня понял и сделал. Скорее всего, в ней будет все, что я до этого уже описывал, но более систематически. Хотелось бы, что бы код был понятен без внешнего описания, но так не получается.

_______________________________________________________________________________________________

Пятница, 5 августа 2011 г.

До реализации функции следует помещать теорию, которая нашла реализацию в данной функции. А в заголовочном файле помещать назначение функции и ее аргументов. Потребителя функции не интересует способ реализации. Его интересуют возможности функции, а так же что требуется для ее использования. А того, кто полез в тело функции интересует, прежде всего, что там реализовано, а уже потом как это реализовано.

Функций в программе тысячи, а то и сотни тысяч. Находить нужную перебором просто неуместно. Они должны быть сгруппированы в более крупные смысловые единицы. Понятно, что я говорю о классах и модулях. Модуль это сборище однотипных функций. Также как и библиотека.

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

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

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

_______________________________________________________________________________________________

Суббота, 6 августа 2011 г.

В основе кода должно быть тестирование. Если метод нельзя протестировать, то такой метод не годится. Можно группироваться вокруг данных. А можно вокруг методов. Это либо объектная, либо структурная парадигма.

_______________________________________________________________________________________________

Пятница, 19 августа 2011 г.

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

Работа с оценкой отчаянно тормозит. Это какая-то точка замерзания. Поэтому пока буду описывать классы и методы.

_______________________________________________________________________________________________

Суббота, 20 августа 2011 г.

Решил тестирование положить в основу. Методически это принципиальный момент. Раньше приоритетом была прозрачность структуры. Однако в итоге стало ясно что, вообще говоря, никакая прозрачность не спасает от ошибок. Только адекватное тестирование в состоянии помочь. Таким образом, будет дан старт новой линейке Ifrit_t

_______________________________________________________________________________________________

Среда, 24 августа 2011 г.

Пока что мне не удается в достаточной мере развести эвристики. Они слишком связанны друг с другом.

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

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

_______________________________________________________________________________________________

Суббота, 27 августа 2011 г.

Функции поиска все еще слишком сложные. В них много постороннего и непонятно как это тестировать. Думаю, что надо уходить от флагов. Правда, тогда непонятно как это все тестировать. Хотя тут правильный принцип, что новая функциональность в новой функции.

_______________________________________________________________________________________________

Суббота, 3 сентября 2011 г.

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

Однако преимущества класса слишком велики. Так что минимальная тестируемая единица будет именно объект.

_______________________________________________________________________________________________

Понедельник, 5 сентября 2011 г.

Все-таки объектная модель не подходит к шахматной программе. Данных мало, а обработчиков много. Так что выделю структуры, а классы будут просто контейнерами функций. Основа будет в функционале.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_j4_4

Опубликованная версия Ifrit_m1

Опубликованная версия Ifrit_m1_1

_______________________________________________________________________________________________

Вторник, 20 сентября 2011 г.

В новых версиях добавил magic-bitboards, mobility и атаку на короля.

Планирую добавить уклонения при шахе. На основе этого сингл - продление. Шахи в статический поиск.

Можно еще раз попробовать IID. Добавить оценку структуры пешек. Можно попытаться разобраться с SSE.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_m1

Опубликованная версия Ifrit_m1_2

Опубликованная версия Ifrit_m1_3

_______________________________________________________________________________________________

Вторник, 27 сентября 2011 г.

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

По тактике версия с футилити лучшая. С разорингом очень глубокая, но много пропускает. А с обрезкой по количеству узлов какая-то тупая.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_m1_4

_______________________________________________________________________________________________

Четверг, 29 сентября 2011 г.

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

И так считать нужно как можно быстрее и как можно полнее. Конечно это противоречивые требования. Так же как отсекать нужно, как можно больше, но при этом нельзя отсекать лишнее.

_______________________________________________________________________________________________

Опубликованная версия Ifrit_m1_4

_______________________________________________________________________________________________