Author: James Robertson
Date: 19:19:07 08/25/99
Go up one level in this thread
On August 25, 1999 at 12:36:12, Bruce Moreland wrote: > >On August 25, 1999 at 04:56:33, Peter McKenzie wrote: > >>On August 25, 1999 at 01:29:55, Bruce Moreland wrote: >> >>> >>>On August 24, 1999 at 22:02:33, James Robertson wrote: >>> >>>>I was looking at my code and noticed that I never get any cutoffs when there is >>>>no available hash move. >>> >>>I don't understand this. >>> >>>> I modifed my code a little, and it sped up, but then I >>>>noticed tactical problems; >>> >>>Are you fixing bugs or trying to make it go faster? If you were trying to fix >>>something, why are you checking speed? >>> >>>>on a certain test position it never finds a fairly >>>>obvious move. Anyway, here is my hash code in my search function. >>> >>>You aren't sounding like someone who is in control of your code. >> >>Such a way with words :-) > >Yeah, I sound pretty harsh there, although I tried to soften it in the part you >snipped. But it's one area where I'm a little religious. I think that it is >important to understand what software is doing, and avoid fixing bugs by >experimentation. Absolutely. Unless you know _what_ caused the bug, it isn't fixed. James > >Especially in a chess program. The things are so volatile because the process >takes place in a tree, which is hard to debug. Almost any change will make a >bug disappear more often than not, meaning that you can "fix" a search bug by a >change in eval, because the tree shape changes enough that the bug doesn't >manifest. > >It is possible, and I believe necessary, to understand bugs in chess programs. >It takes a lot of effort sometimes, but it pays off. > >bruce
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.