Author: Johan de Koning
Date: 23:48:02 10/01/03
Go up one level in this thread
On October 01, 2003 at 06:18:44, Uri Blass wrote: >On September 30, 2003 at 21:10:32, Johan de Koning wrote: > >>On September 29, 2003 at 05:10:00, Uri Blass wrote: >> >>>On September 29, 2003 at 03:13:13, Johan de Koning wrote: >> >>>>Anyway, I think I'll skip the experiment with fully normalized TT entries. >>>>(That's with inactive files removed, and the remaining files flipped/sorted >>>>into canonical form). That would be good for a complete retrograde analysis, >>>>but it won't beat alpha-beta on a fixed starting position. >>> >>>I do not see a reason that it won't beat alpha beta because it does not mean not >>>using alpha beta. >> >>Sorry, that was a bit unclear. >>The it in "it won't beat" was intended to mean full retrograde analysis. >> >>>If you do normalized TT entries then you need to change your TT to include >>>numbers instead of moves and when you try hash move first you may calculate the >>>move based on the number. >> >>I'm not sure if you have some kind of magic unique number in mind. >>As long as normalization is merely shuffling files, there will be an 8<->8 map >>that transforms the board and the move(s) equally in both directions. Though >>the move from the search might be mapped to an irrelevant file. > >My idea was to give every move number when you order the pawns based on the file >and if the file is equal based on the rank. > >For example in the opening position >a3->0 >a4->1 >b3->2 >b4->3 >... >h3->14 >h4->15 >without b2 c2 > >a3->0 >a4->1 >d3->2 >d4->3 >... >h3->10 >h4->11 > >You save in the hash tables only number of 4 bits instead of move and when you >have hash hit you translate the number to a move by generating the list of legal >moves. I'm afraid 4 bits won't be enough. :-) But it doesn't matter, since the issue is correctness rather than data density. >The only problem here is that I did not include symmetry of >abcdefh and acdefgh but it can be corrected by starting the numbers from the a >file in case 1 and starting from the h file in case 2. Or you can keep it simple, and use the file mapping I mentioned. :-) That will still work with aggressive normalization (e.g. steps 3 and 4 in my other post). And BTW, the map is a by-product of the normalization process, so it does not need to be stored. >>>killer moves and history tables if you use them for order of moves do not need >>>to be changed. >> >>IMHO it is more elegant to normalize each position immediately after Make(). >>In that case killers or whatever global move stats need to be discarded. :-) > >You need to normalize the position in order to compare the hash key but >normalizing the position does not contradict also remembering the position of >the board to use it for killers and history tables. >You should have the position twice(normalized and not normalized). True, but I'd rather not rely on killers if that would be the *only* reason to have both versions of a position. And I don't think the history heuristic is of much use for a game in which Zugzwang is the main issue. But attmittedly, I have zero data on NoKillers and YesHistory. ... Johan
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.