Author: Steve Maughan
Date: 12:05:08 09/27/05
Go up one level in this thread
Uri, >I do not understand how having upper and lower bound bound can prevent a >program to solve fine 70 in a short time. Neither do I but that's not the issue. >There is no contradiction between having a productive change and having a bug >and a productive change may include a bug. Again this is not the issue. You're saying that Fruit 2.1 has a "bug" since it cannot solve Fine 70. I'm saying that you cannot say there is a bug in Fruit 2.1 just because it does not solve one position. If Fruit was using a conventional hashing approach then Fine 70 would normally be solved quickly but since it's using something that is really quite different (is anyone else using double bounds?) then I think all the conventional tests go out of the window - Fine 70 included. Take the position below: [D]3qrbrk/ppp3pp/3p1p2/4pPPQ/4P2P/3PB3/PPP5/1K4RR w - - This position is a mate in 4 - Qxh7+ Kxh7 g6+ Kh8 Rg5! then either fxg5 hxg5++ or some other move followed by Rh5++. Most of today's engines will solve this instantly. However Rebel has always had problems. I first discovered this back in the days of The ChessMachine and even recent Rebels have struggles (and Ed knows about it). The reason is due to the move Rg5. If you read Ed's page on programming you see that Rebel stops the search after this move since the computer thinks it is a queen down and the rook move is to a square that allows it to be captured by a pawn. In most situations these heuristics allow Rebel to search deeper and are beneficial. Nevertheless Rebel cannot easily solve this position - so has Rebel a "bug" in its search? I wouldn't say so - it's just a consequence of the heuristics that are used. IMO this is the same as Fruit 2.1 and Fine 70. Regards, Steve PS I'm not sure if the latest Rebels have problems with this position.
This page took 0.01 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.