Smirf and nullmove does not go together

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Re: Smirf and nullmove does not go together

Postby Uri Blass » 15 Dec 2004, 00:16

Not exactly.
Castling is non-reversible move but I do not consider it as a conversion.
It is a private case of every move that lose the right to castle later.

conversion is for me capture or move with a pawn.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Smirf and nullmove does not go together

Postby Guest » 15 Dec 2004, 08:18

Reinhard Scharnagl wrote:Hi Uri,
The way that I use is a safe way to detect repetition unless different positions get the same 64 bit key in the hash.
your method would be save if you would be stepping back only one step instead of two (in the case you would use Nullmove prunings).
Reinhard.


Hi Reinhard,

maybe I'm wrong but your remark seems to suggest that you do not increment the movecounter when you nullmove.

You should, because else your killermoves will be for the wrong side to move ( wich could explain why you don't see an improvement )

Tony
Guest
 

Re: Smirf and nullmove does not go together

Postby Reinhard Scharnagl » 15 Dec 2004, 09:41

Hi Tony,

no, that is a wrong impression. You quoted some speculative thoughts of mine, why there should it be impossible to detect move repetitions. I do that of course using my transposition table.

There have been some postings, which claimed that it would be dangerous to use the cache for to detect position repetitions. But still I have not read some arguments for that. I see no problems in using the cache for to recognize move repetitions.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Smirf and nullmove does not go together

Postby Tony van Roon-Werten » 15 Dec 2004, 11:02

There isn't really. It's a different way of detecting repetitions that has been used before.

For efficiency however, the prefered way is then to use a second (small) hashtable since there will be only a few entries in it anyway.

It becomes a bit more complicated when going multiprocessor, wich is not the case with "walking back the current line"

Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Smirf and nullmove does not go together

Postby Reinhard Scharnagl » 15 Dec 2004, 11:10

Hi again Tony,
For efficiency however, the prefered way is then to use a second (small) hashtable since there will be only a few entries in it anyway
could you please explain, I still cannot see this.

As Smirf uses the transposition table multi-associative, there is for me hardly to imagine such a lost of performance. But it always can be that I may wake up and see new obstacles then I still have missed.

Reinhard
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Smirf and nullmove does not go together

Postby Tony van Roon-Werten » 15 Dec 2004, 13:27

Maybe I didn't understand the multi associative...

Normally a hashtable is multilevel. It means that for checking, locking and unlocking an entry you need to check multiple levels, because your locked entry could have been moved to another level during the search.

This is kind of an overkill for repetition detection, where a single level and smaller (ie 50 K entries ) table should suffice.

Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Smirf and nullmove does not go together

Postby Reinhard Scharnagl » 15 Dec 2004, 13:54

Hi Tony,
... because your locked entry could have been moved to another level during the search.
this is strange to me. In Smirf locking has the meaning, that the matching cache entry could neither be changed nor deleted. What else could the meaning of locking be?

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Smirf and nullmove does not go together

Postby Tony van Roon-Werten » 15 Dec 2004, 14:20

My mistake,

I was thinking more about marking an entry as being part of the current line.

Does this mean that every time you try to write a hashentry, you check wether it's locked ? That doesn't sound nice, altough it's probably very easy predictable for the processor.

As long as you don't plan on using a cluster (no shared hashtable), your method should work fine I think.

Walking back the current line if there haven't been any captures or pawnmoves the last 4 moves is still way easier though ;)

Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Smirf and nullmove does not go together

Postby Reinhard Scharnagl » 15 Dec 2004, 14:30

Hi again Tony,
As long as you don't plan on using a cluster (no shared hashtable),

it seems as if I would have big problems in understanding your items. Here I do not know which parts of the program should be excluded from sharing the TT.

Probably I have a different understanding of a transposition table. I have two kinds of entries within one uniqe cache. One level independent entry for the position representing simultaneously the position itself and the maximum level of its evaluation, and additionally secondary entries representing position evaluations of smaller levels. All those entries are handled equally except of the ability to be locked.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Smirf and nullmove does not go together

Postby Uri Blass » 15 Dec 2004, 14:36

Tony van Roon-Werten wrote:Maybe I didn't understand the multi associative...

Normally a hashtable is multilevel. It means that for checking, locking and unlocking an entry you need to check multiple levels, because your locked entry could have been moved to another level during the search.

This is kind of an overkill for repetition detection, where a single level and smaller (ie 50 K entries ) table should suffice.

Tony


I am not sure what is normally.
This is a known idea but part of the programmers including me did not implement it.

I still have only one level in my hash and there are other things that I plan to do before changing it.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Smirf and nullmove does not go together

Postby Tony van Roon-Werten » 15 Dec 2004, 15:32

I have read some papers about tests between different implementations. Although the difference is quite big with small tables, with todays hashtables sizes it probably doesn't make much difference.

OTOH some people told me they used a rehashing scheme with 4 to 8 probes, wich they found was clearly better.

It never was for me so I just use a 2 level hashtable, wich is easy and efficient enough. I had the impression most people did it that way.

Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Smirf and nullmove does not go together

Postby Reinhard Scharnagl » 15 Dec 2004, 15:40

Hi Tony,
I just use a 2 level hashtable

I do not understand the different usage of the word level here. I use a 4-fold associative cache, but that has nothing to do with the level depending evaluation information of stored nodes.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: Smirf and nullmove does not go together

Postby Tony van Roon-Werten » 15 Dec 2004, 15:52

Reinhard Scharnagl wrote:Hi again Tony,
As long as you don't plan on using a cluster (no shared hashtable),

it seems as if I would have big problems in understanding your items. Here I do not know which parts of the program should be excluded from sharing the TT.

Probably I have a different understanding of a transposition table. I have two kinds of entries within one uniqe cache. One level independent entry for the position representing simultaneously the position itself and the maximum level of its evaluation, and additionally secondary entries representing position evaluations of smaller levels. All those entries are handled equally except of the ability to be locked.

Reinhard.


I see. Some of your wordchoices seem to be nonstandard :)

If I understand correctly: where you say cache, the generally used word is entry, where you say entry, the generally used word is level and where you say level, the generally used word is draft ( I think )

That would mean however that you store a position with the evaluations of several different "remaining depths" (drafts) ? I probably got it wrong.

Anyway, with cluster I mean several computers connected by a fast network. In that case, it's too expensive for 1 computer to probe the hashtable of another computer and find out wich positions are locked.

But your locking scheme would already go wrong when multiprocessing if you don't include the processor id in the lock. Including the processor id would be more effort than simply using the other method for repetition detection.

Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Smirf and nullmove does not go together

Postby Uri Blass » 15 Dec 2004, 16:03

Reinhard Scharnagl wrote:Hi Tony,
I just use a 2 level hashtable

I do not understand the different usage of the word level here. I use a 4-fold associative cache, but that has nothing to do with the level depending evaluation information of stored nodes.

Reinhard.


Hi Reinhard,
I do not understand the meaning of the expression associative cache
and I only guess it from the context.

2 level hashtables means that in one entry there are 2 different 64 bit numbers that are hash keys of different positions.

I guess that you mean to the same(except using 4 entries) by the word
4-fold associative cache.

The word level is used for other meaning and if I get the command level from winboard I understand that I need to read information about the time control.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Smirf and nullmove does not go together

Postby Reinhard Scharnagl » 15 Dec 2004, 18:52

Hi Tony and Uri,
Tony: the generally used word is ...

if there should be a standardization of that, it would be good to know where and by whom. I am not amused always to state I am developing such things on my own. So I am using expressions, which for me are logical. And I doubt on your claimed word usages to be "standard".
Uri: I guess that you mean to the same(except using 4 entries) by the word 4-fold associative cache.

I don't know. In my concept there only could be one position at each entry, because the storage is not sufficient for more. But a position could be stored alternatively at 4 different places depending on the replacement scheme. Overmore the cache could be used virtually for several stored data concerning the same position covering different evaluating levels.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Previous

Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 4 guests