Новости GreKo

Хотел скомпилить Греку, да, видимо, не судьба.
Очень много ошибок приведения типов. Мои компиляторы сами отказываются приводить типы.

Код:

for (piece = 0; piece < 14; piece++)

Вместо нуля пришлось написать PIECE(0), но все равно:

VC++:
error C2676: binary '++' : 'PIECE' does not define this operator or a conversion to a type acceptable to the predefined operator

Intel C++:
error: enumerated type is not allowed


Проходит только так:

Код:

for (piece = PIECE(0); piece < 14; piece = PIECE(piece + 1))

Программа написана на Standard С 99.
Надо использовать опцию -std=c99, как и написано в Makefile. И компилятор gcc (под другими собирать не пробовал).

Я использовал компилятор из пакета MinGW (как отдельно, так и из-под среды CodeBlocks).

Все типы перечисления переделал в int.
Кое-где приведения сделал вручную.
Объявления двух массивов вынес из заголовочного файла.

Теперь все скомпилилось. Щас буду проверять насколько хорошо все получилось

А что, явное указание компилятору версии использованного стандарта - не помогает?
К чему эти взмахи, к чему этот плеск через борт?

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

На этот счёт у нас было даже правило в CEGT, когда там участвовал Alessandro (автор Kiwi). (в 2005 году, когда я там тоже участвовал). Не потому мы ему не доверяли, но просто на всякий случай.

Да нет, тут всё верно. NS совершенно правильно заметил - на больших контролях 5.0 подглючивает, у меня это тоже подтверждается.
Скоро выложу исправленную версию.

Просто не знаю через какую опцию можно указывать стандарт.

Приделал Греке PVS. Сделаю турнирчик трех Грек + Анечка. Интересно, что получится.

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

Вроде в VC++ есть боооольшие проблемы с C99. Они просто его не поддерживают.

И вообще, не пользуйте компиляторы от M$!

Да, есть такой баг. Связан с некорректной обработкой некоторых команд в режиме размышления. Уже исправлен, ждите обновлённую версию.

Да, эндшпильная оценка там сейчас совсем примитивная, нет много чего даже из 2.817 - например, ладейной пешки со слоном неправильного цвета, ничейных тенденций в разноцвете, простых эвристик для KP-K... Дойдём и до этого, со временем...

Код:

1. GreKo 5.0      15.0 / 27
2. GreKo 5.0.0 IK 13.5 / 27
3. GreKo 2.817    13.0 / 27
4. Anechka 0.08   12.5 / 27

Что-то, действительно PVS ничего хорошего не показывает. Хотя моя компиляция и работает примерно на 15% быстрее.

Результаты perft 6 тоже неожиданные.
Скорость оригинальной версии: 4674 kNps.
Моя компиляция: 7751 kNps.

При этом скорость реального перебора всего на 15% больше.

Ты, наверное, assert-ы отключил. Плюс интеловский компайлер всегда самым быстрым считался...

А ты их, что не отключал? Они должны быть только в отладочной версии (и отключаться автоматом при компиляции релиза).

У меня хоть и интеловский, но старый. Всего лишь 6.0.

Код:

1. GreKo 5.0.0 IK 52.5 / 97
2. Anechka 0.08   51.5 / 97
3. GreKo 2.817    45.5 / 97
4. GreKo 5.0      44.5 / 97

Трохи получше стало. На длинных контролях еще лучше должно быть.

Если интересно, вот как я сделал:

Код:

if (legal_moves == 1)
{
    e = -alpha_beta(pos, -beta, -alpha, new_depth, ply + 1, 0);
}
else 
{
    e = -alpha_beta(pos, -(alpha + 1), -alpha, new_depth, ply + 1, 0);
    if (e > alpha && e < beta) e = -alpha_beta(pos, -beta, -alpha, new_depth, ply + 1, 0);
}

И в корне тоже нечто похожее.

У меня в корне окно не бесконечное, оно размеров в плюс-минус пешку от предыдущей оценки.
Кстати, Игорь, обрати внимание - там есть проверка на режим Multi-PV, если он включён, то я увеличиваю размер окна - чтобы у всех вариантов после первого были содержательные оценки, а не отсечения по альфа...

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

не заметил вот эту штуку:

Код:

      if (e > alpha && e < beta)
      {
         strcpy(comment, "");
         alpha = e - ROOT_WINDOW / 2;
         beta = e + ROOT_WINDOW / 2;
      }

Я думал, что окно без ограничений. Теперь понятно почему PVS не дает особой прибавки. Но мне такое окно все равно не особо нравится.

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

Меня режим мульти совсем не интересует.

Здесь разницы и быть не может.

А здесь у меня PVS похуже, т.к. ему нужна стабильность перебора.

Я придерживаюсь именно такого стиля форматирования. Он 1) мне нравится 2) совпадает с корпоративным стандартом организации, где я работаю

Если очень захочется переформатировать, всегда есть под рукой автоматические форматтеры а-ля Artistic Style и т.п. Замену пробелов на табуляцию, и обратно, делает на раз. Плюс корректирует фигурные скобки, отступы в блоках, пробелы в аргументах фукнций и пр. Есть много пред-определённых стилей. Рекомендую: http://astyle.sourceforge.net/

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

PV-узлы у меня не определяются. Все узлы дерева равноправны.

Мне тоже захотелось чего-нибудь с нуля переписать
На всю прогу решительности не хватает. Но до ОФ я уже давно мечтаю добраться

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

Не понимаю, зачем WildCat-у быть на уровне Греко и Анечки, когда он играет на пару-тройку сотен пунктов сильнее?

Хочется сделать новую ОФ. И делать ее постепенно.
Старая написана очень криво.

Не нравится мне вот это:

Код:

#define  VAL_PAWN    (100)
#define  VAL_KNIGHT  (350)
#define  VAL_BISHOP  (400)
#define  VAL_ROOK    (650)
#define  VAL_QUEEN   (1100)

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

Я это уже заметил, поправил ферзя до 1300.