Автоматический подбор параметров движка

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

Нет, не будет - там же достаточно большая рандомость.

ОК! Будет запушена на ночь. Какие результаты и куда отправить ?

Ага, подменил. Но потом она заняла 9-е место и, как понимаю, уже вылетела

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

Нулевая заняла 7-е, то бишь, тож погибла вместе с девятой. Победила 8-ая и сейчас в разгаре 2-й турнир.
Кстати, после появления 200-х(а может и раньше) можно будет обменятся сильнейшими (включив их за место 5-ого места в предыдущем турнире). Или это не поможет?

Я тут напроводил кучу тестов (на мат. модели) Получил много интересных результов.
Но никому ничего не скажу

При хороших алгоритмах обмениваться версиями не имеет смысла.

Если расчет идет на нескольких компах, то лучше после длительного счета объединить по нескольку победителей с каждого компа, провести большой турнир, и новую группу сформировать из победителей этого турнира.

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

Подсчитал, для появления 200-х нужно 120 часов работы генератора.

Не сложно, конечно. В файле Table.txt можно поглядеть результаты последнего закончившегося турнира, напр:
1. 8.prs 11
2. 4.prs 8
3. 3.prs 5
4. 2.prs 4
5. 7.prs 3
6. 1.prs -1
7. 0.prs -2
8. 5.prs -4
9. 9.prs -10
10. 6.prs -14

Это значит, что 1-е место заняла 8.prs (+10пунктов), а последнее 6.prs (-14 пунктов). Последние 6 мест вылетают(умирают) и генерируются новые.
В файле gen_res.txt можно посмотреть результаты текущего турнира, напр:

11.prs
0 0 0
4 3 3 - результат против второго
4 2 4
2 3 5
5 2 3
1 3 6
5 2 3
5 2 3
6 1 3
4 3 3

10.prs
3 3 4 - результат против первого
0 0 0
5 1 4
6 2 2
4 1 5
3 5 2
4 4 2
2 2 6
4 3 3
5 2 3

*****

Делаю, вывод, что 11.prs-10.prs сыграли 433-334. Вроде так, пусть меня поправят, если я не прав.

Ясно, спасибо большое.

Это наверно всё-таки не пункты, а результат

+11 Это типа 50.5 очков из 90.
Или нет?

Ага, очковые пункты.

ИМХО Так-же как и при Ponder-е лучше обдумывать только один лучший ход, так-же и тут - лучше порождать от одного лучшего.

Сохранение половины, и сохранение тех кто в плюсе - дает примерно одно и то-же...

А насчет удобства подсчета - мой код

kolHod:=GenMove;
if kolHod=0 then
Begin
if ochod=true then
Begin
Ochk[pl1]:=Ochk[pl1]-1;
Ochk[pl2]:=Ochk[pl2]+1;
end
else
Begin
Ochk[pl1]:=Ochk[pl1]+1;
Ochk[pl2]:=Ochk[pl2]-1;
end;
end;
end;

Прикольно, 8-ая породила персоналии, которые её же и обыграли, а 7-ая как была в небольшом плюсе так и осталась:

1. 12.prs 22
2. 10.prs 5
3. 11.prs 3
4. 4.prs 2
5. 7.prs 1
6. 8.prs -1
7. 3.prs -3
8. 13.prs -5
9. 2.prs -9
10. 14.prs -15

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

Кстати - увеличение количества особей несильно, но улучшает прибавку в расчет на одну партию!

Насчет неизменяемых особей - оптимально похоже ровно половина...

После почти 14-ти часов счета таблица выглядит так:

1. 34.prs 13
2. 32.prs 12
3. 35.prs 7
4. 20.prs 5
5. 33.prs 5
6. 18.prs 4
7. 26.prs -2
8. 0.prs -8
9. 31.prs -9
10. 30.prs -27

после 40 итераций.

1. Мне кажется маловато изменяемых параметров. Или это только разминка ?
2. Почитав литературку по шахматному программированию осмелюсь высказать предположение о том, что гораздо эффективнее упражняться с параметрами поиска а не статическими весами ОФ. Хотя, это было написано "300 лет тому назад".
Появится время - обязательно попытаюсь склепать что-нибудь свое. Интерестная тема.

Скорей всего это не так - переборные алгоритмы можно достаточно эффективно настроить и вручную.

Все зависит от алгоритма перебора. Если это минимакс или простейшая alpha-beta, тогда да.
А если это что-то навороченное да еще с каким-нибудь ProbeCut то тут вручную замучаешься подкручивать.

? Несколько параметров в переборных алгоритмах по сравнению с десятками и сотнями в ОФ.

Не бывает нормальных программ ни с чистой Альфа-бетой, ни тем более с Минимаксом.

Простейшая настройка NullMove - это вообще один параметр, принимающий значения 2 или 3 И ничего особо не потеряешь приняв всегда R=3

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

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

Так написано было в консоли с утра. 40 Iteration done! По-моему так.

понял

Мало 10 кругов при 10 участниках. Будет давать прибавку только в случае если находимся весьма далеко от экстремума.

при 10 участниках оптимально около 50 кругов. При 30-ти - 6-8 кругов.

Могу выслать программу моделирующую процесс....

На словах - оптимум для модели где сила порожденных определяется формулой -

if Random()>0.95 Then Rating:=Rating[1]+Random(11)
Else Rating:=Rating[1]-Random(51);

(то есть рост силы у каждого 20-го порожденного, в случае роста прибавка от 0 до 10 пунктов Эло)

6 кругов 30 участников, потом без обнуления результатов 6 кругов 22 лучших (результаты первых 6 кругов и второго цикла складываются), поле этого оставляем 11 лучших, и от одного лучшего порождаем 19 особей.


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

Так мне продолжать тест ? Или а данном случае (после разъяснений Сергея) это уже не актуально ?