Методы отладки

Думаю будет интересно узнать, что говорил Торд Ромстад о методах отладки:

# Extend the UCI/XBoard command set with a few commands of your own for use in debugging. In particular, it is useful to have a command for looking up the current position in the hash table and printing the information (score, score type, best move, etc). to the standard output. You can use this to browse the search tree after a search is finished. When you want to know why the program discarded some move, you can make the move and inspect the hash table entry for the corresponding position to find the score and refutation. I've found this to be a very valuable debugging technique, and even have a simple GUI app for browsing the tree (the GUI app communicates with the engine through pipes connected to the standard input and output).

# The technique above can be further enhanced by including lots of additional information in the hash table when debugging the program. I sometimes store complete move lists with information about extension, reduction and pruning decisions for each move in every transposition table entry. Of course this makes each entry huge and greatly slows down the search, but it can be useful when chasing bugs or looking for ways to make the search more efficient.

# Implement an MTD(f) search, even if you intend to use PVS. MTD(f) is great for debugging the hash table; all sorts of obscure bugs which are very tricky to find in PVS or other conventional searches suddenly become easy to spot.

# Whenever you add some non-trivial new function to your program, try to write two versions: One which is very slow and stupid, but almost certainly correct, and one which is highly optimised. Verify on a huge number of positions that they give the same results. Remove the slow version only when you feel 100% sure that the fast version is correct.

# Always make symmetry tests when you add a new term to your evaluation function.

# Run through a simple tactical test like WAC at 5 seconds/move every time you change something important in your search. Don't try to optimize the results, but just make sure that the score doesn't suddenly drop dramatically.

# Check the quality of your move ordering by measuring how often a beta cutoff occurs on the first move, and the frequencies with which the 1st, 2nd, 3rd, ... move turns out to be best at PV nodes.

Надеюсь все понимают по-нерусски.

Мне особенно понравился 4-ый совет.

Совет про MTDF мне не совсем понятен.

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

У меня перебор на Aspiration Search колбасит.
На PVS колбасит непадецки.
О MTD(f) даже страшно и подумать :/

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

Далее программ с обоими этими функциями должна вести себя одинаковым образом (отличия будут только в скорости).

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

Имелось в виду две версии, но дающие абсолютно эквивалентный результат (кроме скорости выполнения).

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

Вряд ли Торда можно считать не уверенным в своих силах. Он явно один из лучших.

NS, жжош!

Ну что это за программер у которого даже нет ошибок в программах? :rolleyes:

Или боятся...

NS, ты ведь пишешь финансовый софт. Ошибки просто используют.

продам задешево 4 бага...

Методы отладки просто ушли в анекдот А ведь в глубине NS прав: надо писать просто так, чтобы отладка была не нужна. Только ни на C ни на навороченном Паскале это просто невозможно.

В общем, бросаем весь этот мусор и переходим на Lisp

Это как? У меня есть только две версии или речь о элементарной программе или о никому не нужной.

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

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

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