Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Bad PV's

Author: Stuart Cracraft

Date: 08:25:59 07/17/04

Go up one level in this thread


On July 17, 2004 at 00:55:50, Dann Corbit wrote:

>On July 17, 2004 at 00:13:39, Stuart Cracraft wrote:
>
>>On July 16, 2004 at 20:04:53, Dann Corbit wrote:
>>
>>...snip...
>>
>>Curious. When I changed the replacement strategy
>>from "replace only if position to be stored has
>>a search depth > than the one being replaced" to
>>either >= or always-replace, the PV's all started
>>looking better. Not just in the opening position
>>of the original test but throughout a game.
>>
>>I am curious as to why this might be as I thought
>>the replacement strategy was important but wouldn't
>>introduce pathology.
>>
>>1. e2e4  0.00   31       21 e2e4
>>2. e2e4  0.00    0       87 e2e4 e7e5
>>3. e2e4  0.01   17      276 e2e4 e7e5 f1c4
>>4. e2e4  0.02    0     1721 e2e4 e7e5 f1c4 f8c5
>>5. e2e4  0.08   17     7608 e2e4 e7e5 g1f3 d7d6 d2d4
>>6. e2e4  0.30    0    31025 e2e4 e7e5 f1c4 f8c5 d2d3 d7d6
>>7. e2e4  1.17   17   120316 e2e4 e7e5 f1c4 d7d6 b1c3 g8f6 d2d3
>>8. e2e4  3.97    0   395322 e2e4 e7e5 d2d3 g8f6 b1c3 d7d6 g1f3 b8d7
>>e2e4  3.97    0   395322 e2e4 e7e5 d2d3 g8f6 b1c3 d7d6 g1f3 b8d7
>>nps=99477 ha=29.00% q=80.0% bc=70% br=3.2% mp=178<>178
>>pawnx=0 recapx=0 qcheckx=24053 checkx=0 futilx=0 qfutilx=34189
>
>Dumb question:
>You do have the side to move included in the hash?

Reran on a test suite with the new hash code after everyone's
input over the past few days (thanks all)
and the various hash code fixes.

It scored about 10% better at 1 second per move. Woohoo.

Bugfixes applied were:

  1) zobrist[2][6][64] -> zobrist[2][12][64]
    (white and black hashes were mapping to the same code in the former,
     now using the latter)

  2) unsigned long long mixed with long long
     Was mixing the two types throughout hash codes. Standardized on former

  3) bugs in updating of incremental hashkey in unmakemv. Avoided
     update by just saving hashkey in move struct prior to makeing a move
     so that unmakemv can just pull it out and replace hashkey with it
     at end of makemv

Although I search any returned hashmove first in the main search()
I do not yet avoid the associated move generation. I wanted to get
all the other stuff clean before proceeding, add other ASSERTS, etc.
Now that the above is done, I can avoid the move generation and that
should help speed it up.

Last up I have to decide on whether to get the new higher speed
dual G5 or an AMD64 to replace this 1GHz PIII dinosaur.

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.