Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: hashing in QS

Author: Gian-Carlo Pascutto

Date: 04:20:16 10/20/04

Go up one level in this thread


On October 20, 2004 at 04:44:44, martin fierz wrote:

>On October 20, 2004 at 03:39:31, Gian-Carlo Pascutto wrote:
>
>>On October 20, 2004 at 02:27:19, martin fierz wrote:
>>
>>>so i want to store the move itself in the hashtable instead of the moveindex
>>>now, as probably everybody is doing.
>>
>>Naah.
>
>naah? i think storing the move itself is much more sensible than the moveindex
>and would have supposed everybody is doing the more sensible thing. at least
>crafty does it that way. you can avoid generating all moves at all times, which
>i have to do now.

The speedup from doing so was quite uninteresting, last time I calculated it,
something like 1% :)

>you can check whether the hashmove is valid or not.

I don't see why this would be so interesting. After all if you select by index
you'll never end up with an illegal move.

> i can't do
>all that with my stupid moveindex. it saves 2 bytes of course in the hashtable
>entry size, but i don't think that is all-important. what are you doing then?

I wrote it this way in Sjeng 1.0 6 years ago and I have never seen a need to
change it.

If you have problems with the indexes not always being valid, for example in the
qsearch, you can just add 200 to the index for qsearch moves, and check for this
after probing.

>well, there are people doing two hashtables anyway, one for shallow and one for
>deep nodes. qs/main search fulfils that type of requirement too.

qsearch is just a case of a "very shallow" node

>if everybody here says "i'm
>doing X and it is much better than all alternatives" i will implement X and not
>play around with it too much.

I would still test it. If you just do as all others how can you ever get better?

--
GCP



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.