Author: Stuart Cracraft
Date: 09:33:19 08/07/04
Go up one level in this thread
On August 07, 2004 at 05:28:12, Andreas Guettinger wrote: >On August 07, 2004 at 03:57:17, Michael Henderson wrote: > >>On August 07, 2004 at 03:52:23, Stuart Cracraft wrote: >> >>>On August 07, 2004 at 03:47:37, Stuart Cracraft wrote: >>> >>>>So here is an 8 ply search of the opening >>>>position without SEE: >>>> >>>>Alpha=-250 Beta=250 Maxdepth=8 MaxTime=9999999 >>>> 1/ 2 e2e4 0.00 35 41 e2e4 >>>> 2/ 4 e2e4 0.00 0 149 e2e4 e7e5 >>>> 3/ 9 e2e4 0.01 17 450 e2e4 e7e5 f1c4 >>>> 4/14 e2e4 0.02 0 2283 e2e4 e7e5 f1c4 f8c5 >>>> 5/17 e2e4 0.06 17 7260 e2e4 e7e5 g1f3 b8c6 f1c4 >>>> 6/23 e2e4 0.40 0 46344 e2e4 e7e5 g1f3 b8c6 f1c4 f8c5 >>>> 7/26 e2e4 1.08 17 119943 e2e4 e7e5 g1f3 b8c6 f1c4 g8f6 b1c3 >>>> 8/31 e2e4 6.11 0 699160 e2e4 e7e5 g1f3 b8c6 f1c4 g8f6 b1c3 f8c5 >>>>e2e4 6.11 0 699160 e2e4 e7e5 g1f3 b8c6 f1c4 g8f6 b1c3 f8c5 >>>>nps=114484 ha=17.00% q=57.0% bc=71% br=NaN% mp=108<>99 >>>>pawnx=0 recapx=0 qcheckx=27853 checkx=0 futilx=0 qfutilx=0 >>>> >>>>And with SEE: >>>> >>>>Alpha=-250 Beta=250 Maxdepth=8 MaxTime=9999999 >>>> 1/ 2 e2e4 0.00 35 41 e2e4 >>>> 2/ 4 e2e4 0.00 0 149 e2e4 e7e5 >>>> 3/ 5 e2e4 0.00 17 439 e2e4 e7e5 f1c4 >>>> 4/10 e2e4 0.02 0 2093 e2e4 e7e5 f1c4 f8c5 >>>> 5/13 e2e4 0.05 17 6550 e2e4 e7e5 g1f3 b8c6 f1c4 >>>> 6/20 e2e4 0.31 0 37096 e2e4 e7e5 g1f3 b8c6 f1c4 f8c5 >>>> 7/24 e2e4 0.81 17 90371 e2e4 e7e5 g1f3 b8c6 f1c4 g8f6 b1c3 >>>> 8/34 e2e4 6.48 4 740555 e2e4 g8f6 b1c3 e7e5 g1f3 b8c6 f1c4 f8c5 >>>>e2e4 6.48 4 740555 e2e4 g8f6 b1c3 e7e5 g1f3 b8c6 f1c4 f8c5 >>>>nps=114244 ha=35.00% q=50.0% bc=68% br=NaN% mp=105<>106 >>>>pawnx=0 recapx=0 qcheckx=9862 checkx=0 futilx=0 qfutilx=0 >>>> >>>>The result is worse (6.11 seconds vs. 6.48 seconds). This is >>>>true of a larger test of problem positions. >>>> >>>>The use of SEE was in the quiescence search only and >>>>involved rejecting any search of a capture whose SEE >>>>value to the to square of the capture was <0, otherwise >>>>the move would be made, legality tested, and if legal, >>>>then the recursive capture search performed (with the >>>>same see test.) >>>> >>>>Is this an abnormal result? What could explain it? I thought >>>>SEE was a shoe-in? >>>> >>>>Stuart >>> >>>The only thing I can think is that the SEE routine is not >>>implemented correctly. For example, after e4, d5 I do a SEE >>>on d5 and it returns -8000 instead of 0. >>> >>>So the SEE itself is clearly broken. >> >>an SEE gave me about 2x speedup overall, using bitboards > > >Hmm, there is something wrong with your implementation. -8000 could mean 1000 - >9000 (pawn - queen)? But why subtract the value of the queen, it does not get >captured? There are only the scores of the two pawns that should be involved in >the score. The queen would be the next_figure at the end but is not captured >because there are no attackers left. The piece that currently is recapturing in >SEE is only the victim in the next round of intereation in SEE. > >So, first swap_score: 100 (move e4xd5, win pawn d5) >second: 100 - 100 = 0; (move Qd8xd5, win pawn d5) > >regards >Andy Andy -- thanks for your input, support, and code. It is working and I tried SEE() with my program. For the details, please see my reply to Alessandro. Stuart
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.