Author: martin fierz
Date: 06:51:20 10/20/04
Go up one level in this thread
On October 20, 2004 at 07:20:16, Gian-Carlo Pascutto wrote: >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% :) right, i always expected this to be rather little. then again, i would take every single % if i could get it :-) the only other speed issue i have with the index thing is that i order my movelist completely before trying the hash move. i could of course defer ordering until i tried the hashmove. BTW with ordering completely i mean i get a "value" for each move, i don't actually order the list, but do so as i go through the list to avoid really ordering everything. > >>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. not even if the index is larger than the number of current legal moves? :-) the real point of interest would be that you catch a hash collision because you see the move is illegal. with the index scheme, you go and search some random move first, instead of let's say a killer move or a winning capture. might not be such a great idea... >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. yes, that's an idea. i wanted to use an additional flag once for qs/main search. the real problem IMO is that you cannot use the qsearch result in the main search with indexes. if you have a move from the qsearch and later come to this point in the main search, you have nothing if you have a QS-index. if you have a QS-move it is very likely a winning capture and might be useful. >I would still test it. If you just do as all others how can you ever get better? true, of course. but if i look at how bad my program is now, then i think i need to get it to the level of "all others" first, and then worry about original ideas! cheers 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.