Author: Dann Corbit
Date: 16:28:44 03/07/06
Go up one level in this thread
On March 07, 2006 at 19:10:19, Stuart Cracraft wrote: >On March 07, 2006 at 13:58:48, Dann Corbit wrote: > >>On March 07, 2006 at 04:39:52, Uri Blass wrote: >> >>>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. >> >>It may find the result by quiesce(). >> >>I think you are probably right about search problems also. >> >>However, having errant terms in his eval, and having search stability problems, >>and yet still solving 3/4 of WAC, I suspect he will make rapid progress once he >>irons out some simple details. > >That is hopeful, but... > >Unfortunately, these issues have cost me a substantial fraction of >my life and I need to move to the next phase in the development but >will sit on this issue until I get some sort of reasonable forward >movement. > >While I am willing to pay significant money directly for consultation that >produces a significant forward advance, I thought the idea of contributing to >the board more palatable since I wouldn't know which volunteer (if any) to pick. >Besides it's cheaper. > >I should recreate Bob's evtest/flip/flop that can be used for any >position to check and compare the evaluations of any given EPD suite >and then run it on WAC itself. A further version could narrow it down >to the function and then the term within the function. > >That is something that does not require a lot of understanding or new >kind of thinking on my part to get to somewhere useful. I'm not tired >of thinking, just tired of banging my head against a wall. > >My goal is simply to get a reasonable tactictian before the next phase >which I doubt will be as hard. The VB program I sent to you by Les Fernandez does exactly that. You can trivially do it also in C.
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.