search efficiency

[MahmoudUthman]

I sort moves in the same way both in search and quiescence, except that in QS
i don't use SEE for move ordering:
1) promotions
2) winning captures
3) equal captures
4) killer moves
5) other moves in history heuristic order
6) losing captures

It doesn't seem good to separate winning captures from equal captures; esearching QxQ before PxB (.e. victim-value order) usually gives better results.

Search efficiency also depends on how much you reduce for LMR and null move.

It is also important what you do when you don't have a TT move in a node with large depth. Do you use any form of iterative deepening in such a node?

IS IID useful Elo wise or does it depend on the TT architecture ? ?

[crybotmark]

hi Marco,

when I wrote and tested Vajolet movegen I compared the perft up to 6 of Vajolet against a reference program(Stockfish)
I still have the 6000 position used for the test
you can find them at:

https://github.com/elcabesa/vajolet/tre ... st/movegen
the script is named parft-random

you can execute it on stockfish and save the results in a txt file with this command

Code: Select all

stockfish <perft-random.txt >out.txt 2>&1 

you'ìll get the result in a very verbose out.txt file.

you can then compare it with the result of your engine.

If i remeber correctly, running all those perft required my pc 1 day of work[/code]

Thank you Marco, I don't think my move generator is defective, as in the past I manually tested it with many positions (not even near 6000 though), and the engine always checks for the current position to be ok after making any move, even in release builds. It never crashed. But I will surely run your script as soon as my testing schedule will permit it

It doesn't seem good to separate winning captures from equal captures; esearching QxQ before PxB (.e. victim-value order) usually gives better results.

Search efficiency also depends on how much you reduce for LMR and null move.

It is also important what you do when you don't have a TT move in a node with large depth. Do you use any form of iterative deepening in such a node?

I actually never tested many other configurations for my move ordering ruotine. It looked sound to me to search good captures before equal ones, but I will sistematically test it as soon as possible. In fact I'd like to know how would you handle captures generation for best results.

Also, I do actually perform internal interative deepening when depth is large enough, no move was found in the TT and the current node is a PV node. I didn't test it rigorously, as when I implemented it I didn't have much hardware to work with, but it looked like it didn't help so much.

Anyway, for anyone interested, Napoleon is open source and (I think), pretty readable: http://www.github.com/crybot/Napoleon

[AlvaroBegue]

IS IID useful Elo wise or does it depend on the TT architecture ? ?

I haven't had any luck with it in RuyDos. I took it out a couple of months ago and the step to remove it looked like noise: 2788-2768-4504.

I tried another variation and I also couldn't get any statistical significance: 1480-1440-2587.

Of course it might work wonderfully for your engine, or perhaps there is some important detail that I didn't get right in my attempts.

[Sven]

[...] I don't think my move generator is defective, as in the past I manually tested it with many positions (not even near 6000 though), and the engine always checks for the current position to be ok after making any move, even in release builds. It never crashed.

There are several possible defects of a move generator (plus make/unmake, plus legality testing code) that will usually not crash your engine, e.g.:
- castling through check
- castling when in check
- setting castling rights incorrectly (without causing an illegal move)
- not setting the ep square after a pawn double step
- missing to generate a promotion
- missing to change the promotion piece back into a pawn during unmake (if that piece does not give check from there)
- missing to generate some legal reply to check
- incorrectly detecting a check when there is none
- letting the moving piece disappear magically
- ...

Most of these problems are unlikely to be present, but so is the absence of all of them ...

My expectation is that at least 50% of all engines that have never been tested with Perft contain at least one bug in the move generator/make/unmake/legality testing code that affects the Perft results.

[hgm]

It is hard for move bugs to measurably depress Elo without leading to frequent obvious blunders. To cost 35 Elo, 1 in every 10 games would contain a gross blunder.

It has always been much more helpful for me to analyze the cause of gross blunders than to do perft. 'Inferno' is in fact my only engine where I extensively used perft. Not to check the move-path counts (for which I did not know the correct values anyway), but to exercise the move generator and Make/UnMake in a wide variety of circumstances, to catch all bugs that would make it hang.