Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Interesting mate test for hashing -- here is some real data...

Author: Robert Hyatt

Date: 21:31:51 09/10/99

Go up one level in this thread


On September 10, 1999 at 22:40:36, Bas Hamstra wrote:

>Disclaimer: I have a simple and rather "young" program. But I think the "core"
>behaves consistent.
>
>I use no pvs but ab with aspiration window at the root. With that I can not
>confirm your results. I happened to use exactly the scheme in the code that was
>posted here. I tried 3 positions: 2 wac (one wac141, the other forgot) and the
>startposition. In all positions I get the fewest nodes playing *any* hashove
>before the captures.


Think about what you just said.  It implies that something inefficient is
going on inside your search, because in fail-low positions, you really are
trying "any move" before trying a capture.  If that doesn't kill your search,
the next question is, how many times to you really use such a move?  You might
simply be lucky enough that it isn't happening that much.

I don't hash q-search, which means my table doesn't have a serious overwrite
problem unless I search for tens of minutes.  Maybe that is why I saw worse
results, because for my tests, the hash table was nowhere near full, as I
always run with hash=384M.



>
>After reading this this discussion I tried skipping the hashmove in case of
>UPPERBOUND. It got more nodes at all depths. I tried using only EXACT moves, and
>got even more nodes.
>


Using EXACT is bad.  In PVS it is fatal, because only a few dozen positions get
stored as EXACT.  The rest are either UPPER or LOWER.  If LOWER, you have a
perfectly good move that just refuted the opponent's last move, and you ought
to try it whenever possible.  For UPPER, I don't see a way to get anything but
a fairly random move...

Unless your eval doesn't have significant positional scores (mine is typically
+/- 2.00 in the middlegame) or if your eval is still very simple and isn't
differentiating between positions very well yet...

>Same results with and without nullmove. My captures (in search and qsearch) are
>ordered basically 100% SEE. I mean even when Attacker < Defender the SEE value
>is determined (will optimize later, if necessary).
>
>Are there any others using naked alphabeta in stead of pvs who can do this
>little test?
>
>Regards,
>Bas Hamstra.
>


PVS is a winner over normal alpha/beta, by at least 10%, and often much
more.  It is worth trying.



>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On September 10, 1999 at 14:01:42, Robert Hyatt wrote:
>
>>As promised, here is some data.  The 'old' column is the standard
>>released version of crafty 16.18.  Which on positions where all moves
>>have a score <= alpha, _no_ move is stored in the hash table, although
>>the bound is stored for later use.  'new' uses the simple trick mentioned
>>by Ed, namely setting best to -inf, then raising it every time a score
>>comes back that is higher, and also remembering the move that went with
>>that score.  That move is now stored in the hash table when this node
>>has been finished.
>>
>>I ran 3 kopec positions, three that aren't tactically motivated, and
>>two that are (4/5) plus wac 230 which is a deep tactical shot that
>>combines both types of themes... Until it finds the deep shot, it
>>appears to be a pure positional problem, then suddenly at depth=16
>>it finds that Rxb4 fails high along a precise tactical line.  So three
>>normal type positions, three tactical positions.
>>
>>pos     old               new
>> 1     4.897M            5.018M  (kopec  2, 11 plies)
>> 2    10.713M           13.563M  (kopec  3, 11 plies)
>> 3    14.739M           15.175M  (kopec  4, 11 plies)
>> 4    25.478M           30.032M  (kopec  5, 11 plies)
>> 5     9.272M            9.083M  (kopec 22, 12 plies)
>> 6    39.971M           41.749M  (wac  230, 16 plies)
>>
>>
>>The results seem quite clear to me.  Trying to figure out a 'best
>>move' at fail-low nodes doesn't work.  Using such moves before the
>>capture search blows the tree up.  Sometimes only a little, other
>>times drastically.
>>
>>As I said, I don't see _any_ way to reliably find the best move
>>at a fail low position.  you might think this trick works, but
>>it doesn't.  This is just a fact of life with alpha/beta.  The search
>>returns _bounds_ that can't be compared to each other to say that
>>"just because this move has a bound <= 200, while this move has a bound
>><=250, clearly the bound <= 250 move is better.  Alpha/Beta just doesn't
>>work that way.  Minimax will.  But trying this made the trees larger
>>in every case but 1, at least for me.  I'll be happy to test any other
>>positions anyone suggests, of course.



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.