Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Nullmove code position

Author: Tony Werten

Date: 01:31:40 10/17/02

Go up one level in this thread


On October 17, 2002 at 02:51:17, Martin Bauer wrote:

>On October 16, 2002 at 19:02:44, Antonio Dieguez wrote:
>
>>Just one thingy, I supose you are looking and probing the position right in the
>>hashtable in respect to extensions. Normally one would look in the hash after
>>doing the extension(i guess is normal) but may be you are doing something to
>>save the pos wih the right depth later, I don't know.
>
>Yes, I make a backup of the depth at the beginning amd write this backup depth
>at the end to the hashtable. Isn't this better? Because if I probe the Hash
>after the extensions and then get a Hashhit, I did the extensions calculation
>for nothing, am I right?

You're correct.

>
>>also, if you dont have a separate hash for qsearch then it may not be worth to
>>probe there.
>
>At the moment I dont use Hash in qsearch, because I noticed that there are some
>problems with the depth. In qsearch my distance in negative, but then I can't
>see the depth, of the calculation. Is it the natural way to fix this problem
>with 2 separate Tables? Of course I can use the same Key and Index than for my
>normal Table?

Easiest is to store quiescence with a depth=0 and in normal search storedepth=
remaining depth+1. ( of course, correct this when reading from hashtable ) Also
make sure you don't "double store" last ply alpha-beta and first ply quiescence.

Tony

>
>Can I do it like this?:
>
>IF (disnace < 0) THEN read/write Table2 ELSE read/write Table1;
>
>Of course I should write an extra qsearch function to avoid such case queryies.
>
>Thanks for your experience,
>
>Martin



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.