OK so here's what I am doing (constructive comments are welcome, as usual)mcostalba wrote:No, I don't think you have understood. For each check you can have multpile evasions at the next ply.bob wrote: but since I was already excluding unsafe checks, excluding unsafe evasions didn't help me at all...
Say you are doing a safe check and at the child node you have 5 evasions to try. The idea is to try just a sub-set (say the first 2) and then discard the other 3.
This is the idea of Joona.
Quiescent search
- Generate all captures and promotions, and quiet checks (by pieces only not K discovered checks or P push checks) at depth 0.
- Prune < 0 SEE the same way as SF, with the PV condition and the evasionPrunable condition. I will eventually test this dubious PV condition, as well as the one for recaptures.
Hash tables
- I only use the htable for move ordering at PV nodes, and I use it for pruning non PV nodes. This is of course because of 3/50 moves rules and being able to display an untruncated PV line (although displaying a full PV is the least of my concern)
- I use it in the search as well as the qsearch, and even at the root node (my root node behaves like any search node, even for extensions, so there's no problem there)
- I never use a hash entry that was built by the search in the qsearch. The trick or that is that I also use the htable for storing the eval, and I store a NoEval at search nodes, where the eval is useless (for the moment as it is just a PVS search with basic extensions, nothing fancy there). So when I see a NoEval score in the qsearch I know the hash entry shouldn't be used there
Move ordering
- htable move first, mate killer next
- captures and promotions have a sort score equal to the SEE (rescaled)
- quiet moves:
first the killer moves. then all other quiet moves sorted by history score, rescaled to fit in the interval ]-Pawn,+Pawn[. Unfortunately that also means that a NxB capture having a see = B-N = 0.10 Pawn for instance is mixed with quiet moves history scores
With a non existant evaluation (PSQ + simple Mobility function + interpolation middlegame/endgame), all this seems to behave quite well. Nothing earth shattering though, but I get the following results on the WAC 300 test:
256/300 with 2 sec/move and 16MB Hash
265/300 with 5 sec/move and 64MB Hash
I think that's enough for the search itself at the moment. The next steps for me are:
1/ code a basic UCI interfacing code (I really hate that part, and will probably get some inspiration in Fruit for that)
2/ add the following *basic* endgame knowledge, like a score incentive to push a lone King on the edge or in an (appropriate is X=BN) corner in a KXK final where X is enough to mate.
3/ just play against my engine manually in some endgame positions to see how stupid it is and what I can do about it
4/ then probably get back in the search and mees things up with Razoring, Futility pruning, and LMR...
