Author: Uri Blass
Date: 01:39:52 03/07/06
Go up one level in this thread
On March 07, 2006 at 03:47:06, Dann Corbit wrote: >On March 07, 2006 at 03:02:17, Uri Blass wrote: > >>On March 07, 2006 at 00:46:27, Dann Corbit wrote: >> >>>On March 07, 2006 at 00:41:55, Dann Corbit wrote: >>> >>>>On March 07, 2006 at 00:34:48, Stuart Cracraft wrote: >>>> >>>>>On March 07, 2006 at 00:31:45, Dann Corbit wrote: >>>>> >>>>>>On March 07, 2006 at 00:27:43, Stuart Cracraft wrote: >>>>>>[snip] >>>>>>>Very interesting indeed. A clever test. >>>>>>> >>>>>>>If one's results do not rotate approximately as described >>>>>>>for the four positions and you say the evaluation is an >>>>>>>issue, what kinds of evaluation issues have you seen that >>>>>>>could explain it?!? >>>>>> >>>>>>The most common thing that I see is something that is good for white being >>>>>>counted as positive for black also on the evaluation. Often, when we are >>>>>>writing the eval, we are thinking from the perspective of white. And so if we >>>>>>are not very careful, we may invert the sign of some evaluation component and >>>>>>count something that is good for white as something that is good for black (or >>>>>>vice versa, though the reverse is seen less often for some reason). >>>>>> >>>>>>There are, of course, many other possible causes besides that. >>>>> >>>>>A good point. I try to avoid that by always doing things from the >>>>>side on move, almost always. There are a few in there however with >>>>>respect to white and black specifically, but they are then folded >>>>>together with the stm variable and stm^1 which translate to white/black >>>>>or black/white depending on who's on move. I could try this: rerun >>>>>your rotation test with successively less in the evaluation table >>>>>until nothing but material and see what happens. >>>> >>>>Right. If you have divided off the eval components, you could binary search >>>>until you find the problem component. >>>> >>>>Now, we do not know for sure that it is an eval sign problem. However, the fact >>>>that the records are similar in pairs makes it very suspicious. >>> >>>I guess that when you have gotten your eval symmetrical, you will miss less than >>>ten problems on WAC. >> >>I think that you are wrong here. >>Stuart may have evaluation bugs but his main problem is the search. > >I think it likely that it is both. > >Given: >5rk1/2p4p/2p4r/3P4/4p1b1/1Q2NqPp/PP3P1K/R4R2 b - - bm Qg2+; id "-rotXTDa.1"; >1kr5/p4p2/r4p2/4P3/1b1p4/pPqN2Q1/K1P3PP/2R4R b - - bm Qb2+; id "-rotXTDg.1"; >r4r2/pp3p1k/1q2nQpP/4P1B1/3p4/2P4R/2P4P/5RK1 w - - bm Qg7+; id "-rotXTDc.8"; >2r4r/k1p3pp/PpQn2q1/1B1P4/4p3/R4P2/P4P2/1KR5 w - - bm Qb7+; id "-rotXTDe.8"; > >When I changed to material only eval, here is the result: > >st 5 >ts >position file? [wac.epd] rot.epd ># of test positions to test? 4 >maxtime = 500 >Interrupt current ply and return move at timeout >Testsuite: rot.epd 4 positions >*** Problem Solution(s): Qg2+ (bm) >[D] 5rk1/2p4p/2p4r/3P4/4p1b1/1Q2NqPp/PP3P1K/R4R2 b - - bm Qg2+ >*** Problem Solution(s): Qg2+ (bm) >-- ** -- ** -- BR BK ** >** -- BP -- ** -- ** BP >-- ** BP ** -- ** -- BR >** -- ** WP ** -- ** -- >-- ** -- ** BP ** BB ** >** WQ ** -- WN BQ WP BP >WP WP -- ** -- WP -- WK >WR -- ** -- ** WR ** -- >mv 1 stage 0, black to move, computer plays black >hash=62305c813f5fad4 >pawnhash=3da7edf6c1ba87ea >0 0 0 0 0 0 >Alpha=-400 Beta=400 Maxdepth=9999999 MaxTime=500 xboard=1 >Ply Score Time Nodes PV >1. 40 3 12 c6d5 e3d5 >1. 900 5 74 f3g2 e3g2 Qg2+ is a sacrifice so it is not logical so if the computer choose it at depth 1 then it means that there is a serious bug. Uri
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.