Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Null-Move: Difference between R = 2 and R = 3 in action

Author: Sune Fischer

Date: 12:07:20 07/21/02

Go up one level in this thread


On July 21, 2002 at 14:35:49, Robert Hyatt wrote:

>On July 21, 2002 at 03:16:40, Sune Fischer wrote:
>
>>On July 20, 2002 at 22:22:22, Robert Hyatt wrote:
>>
>>>On July 20, 2002 at 08:13:44, Gian-Carlo Pascutto wrote:
>>>
>>>>On July 20, 2002 at 08:04:01, Sune Fischer wrote:
>>>>
>>>>>I think it matters "a factor of 2".
>>>>>
>>>>>1) it helps you to prune
>>>>>2) you get better evaluation in the upper plies when you can return a score
>>>>>based on a deeper search.
>>>>>
>>>>>number one will show itself directly because you iterate deeper, the second one
>>>>>you don't "see", but it does improve depth along some branches in the same way.
>>>>
>>>>1) I get +- 10% hash hits (and less prunes) in typical middlegame. Not enough to
>>>>matter a factor of two (but I didnt check this so not 100% sure).
>>>>
>>>>2) Uh?
>>>>
>>>>--
>>>>GCP
>>>
>>>
>>>Run your program with a tiny hash and a deep search.  Then a big hash and
>>>a deep search.  In middlegame positions this will be at least a factor of
>>>2x.  Measure time to depth.  Small hash might take 4 minutes to get to depth
>>>12, then big hash will take around 2 minutes...
>>
>>You shouldn't measure time to ply, that would not give you the full benefit of
>>the hash. You should use time to find the right move.
>
>
>In years of testing, at least in middlegame positions, time-to-ply and time-to-
>solution are exactly comparable.  IE just search to the _end_ of the ply where
>both will find the answer and the times can easily be compared.
>
>If you take endgame positions where hash artifacts occur, such as fine 70
>where the solution is found at an earlier ply (when your move ordering is
>bad) with hashing than without, then you are right.
>
>But at least for middlegame positions, I don't often see finding something
>a ply or two earlier, although it does happen in some cases.  But when that
>happens then I ignore _everything_.  If you find the solution move two plies
>earlier, then you will have a totally different tree shape than the program
>that doesn't find it as quickly, so comparing anything there is difficult.
>
>
>
>>
>>I have never seen the hash bring only a factor of 2, even in middlegame.
>>Last I tested I saw a mate in 5 being solved in 1/4 of the nodes with the hash.
>>Some things are also spotted a ply sooner because of the hash, so time to ply
>>wouldn't be the right way to estimate the value of the hash.
>
>I would agree when that happens.  But note that I really don't use _tactical_
>positions for comparison.  I use "normal" positions that have no tactical
>solution, so that this doesn't happen.
>

Well you can prove anything you set your mind to, you just have to design the
right tests :)

Personally I'm not interested in artificial tests without tactical positions.
IMO, you should have a good spread of easy, hard, tactical, positional, and
"whatever" positions like in a real game if you want to measure the hash effect.

On the other hand it doesn't really matter, because we agree that it works well,
just not how much it works :)

-S.



This page took 0.11 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.