Author: Uri Blass
Date: 07:13:49 08/16/03
Go up one level in this thread
On August 16, 2003 at 09:34:32, Ed Schröder wrote: >On August 16, 2003 at 09:24:42, Uri Blass wrote: > >>On August 16, 2003 at 09:13:25, Ed Schröder wrote: >> >>>On August 16, 2003 at 03:24:47, Johan de Koning wrote: >>> >>>>On August 15, 2003 at 04:03:32, Gian-Carlo Pascutto wrote: >>>> >>>>>On August 15, 2003 at 02:03:28, Johan de Koning wrote: >>>>> >>>>>>The job of an engine is to search a position, >>>>> >>>>>The goal of an engine is to play chess games. >>>>> >>>>>A user may use it to analyze positions. In that case, not being >>>>>able to remember analysis when moving throughout the variations >>>>>is a weakness, not a strength. >>>>> >>>>>>and the result should depend only >>>>>>on that position. Like the power of a car engine should depend only on its RPM, >>>>>>not on how fast the car moves or how fast the car moved 1 minite ago. >>>>> >>>>>Power doesn't mean anything. It's an internal parameter >>>>>that only indirectly relates to real world performance. >>>>>Acceleration or speed does. They do depend on past situations. >>>>> >>>>>>Sticky TT (or reorderd piece lists :-) cause the engine to have a mind of its >>>>>>own. Things with a mind of their own, like cats and (wo)men, are unreliable and >>>>>>don't make a good tool. >>>>> >>>>>You sound like a kid that believes in Santa Claus. >>>>> >>>>>Nondeterminism is something you can live with. Forget about getting >>>>>the engine working on multiprocessor if you don't. >>>> >>>>So far you sound like someone trying to mimic Vincent. :-) >>>> >>>>I listed predictability as the first of 7 reasons to clear the TT. I did not >>>>list any reasons to preserve the TT, though they do exist (else there wouldn't >>>>be any discussion). >>> >>>But he wants to hear the 8th reason :) >>> >>>Here is my guess, you are marking all kind of positions in the HT to extend that >>>position the next time (iteration). It's the reason why you can not afford to >>>have a big HT and why you must clear it, otherwise the tree would explode. >>> >>>Am I close? >>> >>>Ed :) > > >>I do not understand the reason that you give. >> >>I see no reason that you have to mark all position in the hash tables and >>I see no reason to extend all positions in the hash tables for the next >>iteration. > >Singular Extensions comes to mind, you mark a move as singular in the HT and >search it 1 ply deeper the next iteration. There are plenty of other >possibilities, dangerous pins, threats, mate threats, or any other information >you can extract from the search paths. > >Ed ok so it is extensions of part of the positions in the hash tables and you can control that part so there is no reason that more hash tables are going to be a disadvantage and you can clear the information about extensions in the next iteration without clearing the information about order of moves. The only explanation is if you find at the last moment something productive but the result of the implementation is that more hash tables is not better and you have no time to change it because you need to release something but in theory bigger hash is better if you do the right tests and I also believe that in theory clearing the hash tables is not the best thing for playing strength even if there is some reason that it is the best for your program and you have no time to test changes until the release. personally I am not sure if bigger hash tables is always better for movei because I have some productive pruning that may be different with different hash tables(I compared only pruning with hash tables and not pruning with the same hash tables). Uri
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.