Author: Ulrich Tuerke
Date: 09:48:01 06/21/03
Go up one level in this thread
On June 21, 2003 at 08:04:17, Dave Gomboc wrote: >On June 20, 2003 at 10:17:10, Ulrich Tuerke wrote: > >>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 > >What Uri is suggesting is that it _is_ a question of pruning: specifically, that >Chess Tiger and Deep Sjeng are doing some unsafe pruning that causes them to >miss the solution. I understand, but I doubt it. When an amateur program like mine on outdated hardware like an 80386 can solve it very quickly, then you really have to prune a lot in order to make Chess-Tiger miss the solution on hundreds times faster hardware. I guess that you would have to implement things like: "pawn advancing to 8th rank: better prune off because it could be too interesting". -:) Seriously, I have been using this position for test for more than 10 years now and my experience is, whenever an engine version had been missing the solution, something had been spoilt in the hash algos. Uli But anyway, only Gian-Carlo and Chris do really know. > >Dave
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.