Author: martin fierz
Date: 06:50:25 10/18/04
Go up one level in this thread
On October 18, 2004 at 09:01:55, GeoffW wrote: >Hello Martin > >Thanks for the response > >>>I am using SEE to order the capture moves in my Q search. >>>Move ordering in the normal search is still MVVLVA as my SEE is quite slow >> >>surprising, since the closer to the root of the tree you are, the less important >>it gets to be fast vs intelligent. i.e. if you can order moves better and slower >>vs worse vs. fast, then you should do the better and slower close to the root, >>the worse and fast closer to the leaf nodes. > >Yes, that makes sense now I think about it. It was ages ago when I first got >SEE working, so I could have incorrectly concluded that SEE wasn't good in the >normal search due to my lots of other bugs, or my initial poor understanding of >SEE and searching. (Makes mental note to try SEE again in the future in the >normal search !) >I did think from what I had read here that typically people use SEE only in the >Qsearch and not the main search ? Maybe that isn't true ? hi geoff, my first SEE wasn't very good (no see is ever very good i think, but mine was particularly bad!). i didn't detect x-ray attacks, e.g. Bc2Qd3 vs Kg8 Ph7, my see would think Qxh7 mate was losing a queen :-) at that time, i also tried see for move ordering in the normal search, and it didnt help. i fixed it since (the part with the xrays), and now it does help, i'm searching smaller trees than before. no big surprise in fact. so perhaps your weird results can be explained by your see being buggy. did you check it's working ok? see is used in qsearch to prune obvious bad captures - although it will often miss something of course (pinned pieces, overloaded defenders etc). but it is also used in the normal search for move ordering, and i don't really know which part is more important. you can even use see to check non-captures for whether they lose material or not. >looks like this bit of code does need a safety margin as I suspected. When I did >some brief testing a few days ago with this, I was rather surprised that the >margin needed to stop it playing worse than the non-SEE version seemed to be >huge. IIRC it was around 5 pawns or so, maybe even higher. I do need to do some >proper measurements on this however. 5 pawns sounds like an awful lot! did you do your testing with material-eval or full eval? since in your code you had material eval, which makes little sense to me. you have to get the eval anyway in qsearch since you want to know whether you can stand pat, so you have it available - why not use it? hmm, and also your "brief testing" sounds suspicious: my advice is never to do brief testing! test these things properly, or don't test them at all, there is no point to it. when i change something in my program, i play 240 games to validate it. takes f***ing long, but it's the only way to do it. test suites are good to show you if you've broken something, but that's all they are good for. cheers martin
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.