Author: Uri Blass
Date: 08:03:13 06/20/03
Go up one level in this thread
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 I did not claim that it is not easy to solve the position without pruning and extensions. I claim that it is possible not to solve the position because of adding a new pruning rule. Movei cannot solve it because of different reason(not using hash tables for pruning) but I believe that Chris and GCP do not do it. I have reasons not to improve this at this point because I feel that doing it may limit my possibilities to try different ideas than other programs. I have a lot to improve but even at this point movei is strong enough to have practical chances against everything(the best result that I got from testers was beating yace padderborn 4-2 at 40/40 time control but I know that movei is clearly weaker than yace at this point) 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.