Author: Ulrich Tuerke
Date: 07:17:10 06/20/03
Go up one level in this thread
On June 20, 2003 at 09:37:14, Uri Blass wrote: >On June 20, 2003 at 09:12:57, Ulrich Tuerke wrote: > >>On June 20, 2003 at 07:34:03, Uri Blass wrote: >> >>>On June 20, 2003 at 07:29:35, Mike Byrne wrote: >>> >>>>On June 20, 2003 at 06:15:09, Joachim Rang wrote: >>>> >>>>>On June 20, 2003 at 05:05:24, Vincent Lejeune wrote: >>>>> >>>>>> >>>>>>I'm running a test with Chesstiger 15 and the Valentin Albillo test set (see >>>>>>http://www.talkchess.com/forums/1/message.html?301806) and what a surprise >>>>>>Chesstiger have a problem with the first position the well known FINE 70 (Kb1!); >>>>>>Crafty, Fritz, Hiarcs have no problem with this position; so why CT ? hashtable >>>>>>weakness, pruning weakness or somehting else ? Christophe, an idea ? >>>>>> >>>>>>>> >>>>>>I will publish the result for all positions later Celeron@875, 96 MB hash, 15 >>>>>>min/pos >>>>> >>>>> >>>>>DeepSjeng has also Problems. At least in beta stage when I tested the program. >>>>>Gian-Carlo replied to my message with the argument, that tuning an engine for >>>>>this position makes it weaker in general pawn endgames. I'm sure the views >>>>>differ on that position but maybe Theron agrees with Gian-Carlo that this >>>>>specific position is an artificial one. >>>>> >>>>>regards Joachim >>>> >>>>this position is a question of search not tuning... >>> >>>I think that GCP talked about tuning the >>>extension and pruning rules. >>> >>>I can imagine that a change in the pruning rules that is productive for other >>>positions is not productive for this position. >>> >>>I do not believe that it is impossible to fix the problem in a productive way >>>and I guess that the real reason is that in the same time of fixing the program >>>it is possible to do bigger improvements. >> >>I don't think that solving this position is a matter of pruning or extensions, >>since Comet could solve it on a 16 MHz 80386 in a few seconds. > > >It only proves that it is a matter of pruning because Comet had not the same >pruning that tiger or sjeng had. No, it doesn't. As I said, solving this position is not a question of pruning or extending. The question is how to calculate a secondary index to the hash table when the default index points to storage which is already in use. I suspect very much that Chris and GCP can very easily improve their engines in positions of this kind by having a closer look to their replacement schemes. Uli > >I guess that GCP can easily change Sjeng not to have the pruning rules that it >has in order to solve it but the problem is that sjeng is going to be weaker >only in other pawn endgames. > >I do not know but I guess that the pruning is about pruning lines that lose a >lot of tempos. > >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.