Author: Steve Maughan
Date: 01:50:24 06/15/05
Go up one level in this thread
Good question - and one that I have asked myself before. Here's my take: 1) I think fundamentally Fruit is just a well coded application with few bugs. 2) Fabian has liberally used "asserts" to catch simple bugs - I'm sure that this has helped. 3) Most of the code is color independent - this will have reduced the number of bug (of the type which are tough to catch). 4) Although it is written in 'C' most of the code has a form of encapulation from (i.e. object orientated) where the "board" parameters is passed to most routines. I think this was probably a design decision that will allow Fruit to go SMP at some stage. I think it also makes the code clean which in turn reduces the bugs. All of the above reasons are just good coding practice. I think there are some other ideas that are chess / game specific. 5) Fruit does not do hash cuts at PV nodes. I think this is another area that can help catch bugs. If you do not see a proper PV there is something wrong. 6) The null move criteria is solid i.e. no null moves if current eval < beta or depth < 3. 7) I think a big win is the internal iterative deepening implementation which allows Fruit to dig itself out of deep fail high / lows. I think this also reduces the Branching Factor to about 2 which allows Fruit to search really quite deeply where other engines get bogged down. 8) I'm not sure but the hash method used in Fruit 2 may also be superior to the standard hash method. Fruit holds an upper and lower bound score for each position - this may also help in big fail high / low situations. 9) Fruit doesn't do that much pruning at the edge, or close to the edge of the tree. I think this probably adds to the stability of the search. I think all of these can be summarized as "excellent coding style which implements solid, well knows heuristics while not trying to be too clever". I really do think that Fruit is a landmark program. It shows (me) that bug free code should be the #1 priority. Yes I know it's obvious but the mistake most beginners make is to concentrate on speed first and assume that they will iron out any bugs that arise - in chess programming, due to the recursive search nature, these bugs are more than a little tricky to find. I'm rewritting many of the routines in Monarch to make them color independent and adding testing code for *each* routine. Regards, Steve
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.