Author: GeoffW
Date: 06:01:55 10/18/04
Go up one level in this thread
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 ?
>
>>2)
>>I am using the SEE score for a capture to prune moves at generation time
>>Bit of pseudoCode
>>
>>addMoveToMoveList()
>>{
>>#ifdef USE_SEE
>> if (scoreBasedOnSee(sideToMove,from,to) < 0)
>> return;
>>#endif
>>etc..........
>
>this looks HORRIBLE! if you are doing this in the qsearch, fine, but you don't
>state that. if you really do this, you will reject moves in your normal search
>based on SEE alone, which is something you surely don't want to do !?
Sorry my description was a bit ambiguous. All of my SEE code is in qsearch only
so that prune doesn't happen in the normal search.
>i use
>
>if(current_eval + see(move) + safetymargin < alpha)
> continue;
>
>so i use the real evaluation, not the material eval, and i add a safety margin,
>which at the moment is 1.5 pawns for muse. i haven't tested this extensively
>though. i did some tests with 1.0 1.5 and 2.0 pawns, and they were rather
>inconclusive.
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.
I thought that the need for this high margin value was more likely due to a bug
I had somewhere or maybe some concept/idea I had misunderstood.
I have a distinct tendency for getting my +/- scores reversed and alpha's and
beta's reversed at every possible opportunity :-)
Geoff
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.