Author: Stuart Cracraft
Date: 17:36:52 07/11/04
Go up one level in this thread
On July 11, 2004 at 15:50:56, Eric Oldre wrote:
>On July 11, 2004 at 15:21:07, Will Singleton wrote:
>
>>On July 11, 2004 at 14:35:50, Eric Oldre wrote:
>>
>>>[D]8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1
>>>
>>>I ran my engine on the fine 70 position above. which Anthony Cozzie recommended
>>>to me last night as a good position to test for transposition table issues.
>>>below is my new engines analysis of the position.
>>>
>>>(note, I'm not yet sure if I will call it "Murderhole2" or give it a completely
>>>new name)
>>>
>>>Murderhole2 release WB2 25 MB:
>>> 1 00:00 1.48 a1b1
>>> 2 00:00 1.40 a1b1 a7a8
>>> 3 00:00 1.45 a1b1 a7a8 b1c1
>>> 4 00:00 1.40 a1b1 a7b8 b1c1 b8c8
>>> 5 00:00 1.40 a1b1 a7b8 b1b2 b8c8 b2c1
>>> 6 00:00 1.40 a1b1 a7b8 b1b2 b8b7 b2c1 b7c8
>>> 7 00:00 1.40 a1b1 a7b8 b1b2 b8b7 b2b1 b7c8 b1c1
>>> 8 00:00 1.40 a1b1 a7b8 b1b2 b8b7 b2b1 b7b8 b1c1 c8b8
>>> 9 00:00 1.45 a1b2 a7a8 b2c1 a8b8 c1d2 b8c8 d2c2
>>>10 00:00 1.40 a1b2 a7a8 b2c1 a8b8 c1d2 b8c8 d2c2 c8b7 c2c1 b7c8
>>>11 00:00 1.45 a1a2 a7a6 a2b2 a6b6 b2c3 b6a7 c3d2 a7a8 d2c2 a8b8
>>>12 00:00 1.42 a1a2 a7a6 a2b2 a6b6 b2c3 b6a7 c3d2 a7a8 d2c2 a8b8 c2d2 b8c8
>>>13 00:00 1.47 a1b1 a7b7 b1c1 b7a8 c1d2 a8b8 d2e1 b8b7 e1f1 b7c8 f1g2
>>>14 00:01 1.45 a1b1 a7b7 b1a1 b7c8 a1b2 c8b7 b2b3 b7c7 b3c4 c7b6 c4c3
>>>15 00:02 1.47 a1a2 a7a8 a2b1 a8b8 b1a2 b8c8 a2a3 c8b8 a3b3 b8b7 b3b2
>>>16 00:04 1.45 a1a2 a7b7 a2b2 b7c8 b2c3 c8b7 c3b2 b7c8 b2c3 c8b7 c3b2 b7c8
>>>b2a1 c8c7 c1b1
>>>17 00:08 1.48 a1b1 a7a8 b1c1 a8a7 c1d2 a7b6 d2e2 b6c7 e2f3 c7d8 f3e2
>>>18 00:12 1.58 a1a2 a7a8 a2b2
>>>19 00:35 1.60 a1b1 a7b8 b1c1 b8c8 c1c2 c8c7 c2d3 c7b6 d3e2 b6c7 e2e3 c7d8
>>>e3d3 d8c7
>>>20 01:12 1.62 a1b1 a7b7 b1c1 b7c7 c1b2 c7c8 b2c2 c8b7 a2b2 b8c8 b2c2 c8b7
>>>a2b2 b8c8 b2c2 c8b8 a3b3 b8c7
>>>21 03:51 1.62 a1b1 a7b7 b1c1 b7c7 c1b2 c7c8 b2a2 c8b8 a2a1 b8b7 a1b1 b7a7
>>>b1c1 a7b7
>>>
>>>it does eventually at depth 19 decide on the correct answer of a1b1.
My program doesn't see the right move for the same wrong reason (as yours)
until several ply later. So I am curious about the difference.
however, it
>>>looks like it is simply it trying to avoid the draw by repitition and counts
>>>itself as ahead due to it's extra pawn. it doesn't get a crushing score at this
>>>depth at all.
>>>
>>>at this point the eval function is simply static material and piece/square value
>>>tables, i hope to add more advanced techniques this week.
>>>
>>>I'm looking for some advice in interpreting these results.
>>>
>>>a) did I just not let it search deep enough?
>>>b) does the fact that it took 3:51 to reach depth 21 indictate a issue with my
>>>tranposition table? it was running at 1,200,000 nodes/sec.
As you know, nodes/sec is meaningless depending on how you count
nodes (quiescent frontier nodes only? quiescent plus pre-frontier
non-quiescent? before or after cutoff?) Let's concentrate on the
moves and the reasons since that's better, I recommend.
>>Yes. As you probably know from running other programs on this, it should blow
>>thru 21 ply in less than a second. Do you use two tables or one? Depth or
>>always replace?
>>
These are good questions.
>
>currently i'm using only 1 table, and always replace, thinking more carefully
>that could very well be the cause of the issue, as the useful results may be
>getting thrown away. I'll try and get a two table scheme in place to see if that
>changes my results, or maybe switch to a replace if deeper scheme and see if
>that alone will fix it. (eventually i'll move to a 2 table system either way)
>
>I'll make sure to report back the results when i get some.
Good.
I experimented a bit with the replacement mechanism for a single-tier
hash table, the one in my program. It had no effect on the particular
Fine #70 but did have an effect amounting to 6% more problems solved
for the first 50 problems of Reinfeld WAC.
always replace
*** 78% 39/50 39.28 6815579 136312/1/173499 0/0/244611/00/1046538
replace if new depth >= hash table entry's depth
*** 80% 40/50 41.59 7046263 140925/1/169414 0/0/241311/00/1040909
replace if new depth > hash table entry's depth
*** 84% 42/50 41.17 7108063 142161/1/172639 0/0/239152/00/1031626
In this limited test, the winner for a single-tier hashtable is to always
replace if your new position for storage has a searched depth greater than
the entry in the table it is replacing.
I was a little surprised at this. I had "always replace" (#1) before
but now have left it at #3 and will do some more extensive overnight
testing to see if it should stay.
>
>>>
>>>if there is a issue with my transposition table, could it be due to not having
>>>random enough keys? here is the code i'm using to generate the numbers.
>>>
>>>U64 rand64(){
>>> U64 retval = 0;
>>> retval = (retval <<15) | rand();
>>> retval = (retval <<15) | rand();
>>> retval = (retval <<15) | rand();
>>> retval = (retval <<15) | rand();
>>> retval = (retval <<15) | rand();
>>> return retval;
>>>};
This sounds very unlikely. If concerned, avoid the rand() of your
compiler and just throw in that Knuth/Hyatt code I sent. You'll never
worry again about compiler or architecture vagarancies.
You'd probably simply do much better to implement square of the pawn
with a couple hundred point strength gain. It would clarify a huge
number of the nodes with Fine #70. If enemy king is outside of
the square of your passed pawn and does not have the move, etc.
Stuart
This page took 0.01 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.