Author: Don Dailey
Date: 21:00:42 02/03/99
Go up one level in this thread
On February 01, 1999 at 03:45:14, Bruce Moreland wrote: > >On January 31, 1999 at 23:29:16, Don Dailey wrote: > >>Actually, YES. I am horribly pragmatic, but am gradually changing as >>I get older. For instance if the lock slowed down the program 6 percent, >>but a combination of testing and my best guess judgement calls indicated >>that I would lose 1/2 point every 30 games because of it, I would accept >>the risk because it means the program is slightly stronger. > >Play on ICC and you'd know that this is an extremely bad tradeoff. What you say >might be true if you play opponents that are equal to your strength, or above, >but if you start playing hundreds of points down all the time, you have to win >every game. I don't think I buy this one at all, but you could be right. You are basically claiming that a buggy program exhibits an intransitive relationship between weaker and stronger players. But if your program is playing hundreds of points down, you will probably recover from many, if not most errors (depending on how far down you are playing.) Getting an awful score in the tree is not some isolated event that can only happen with a hash mismatch. It is my understanding that your program does a swapoff evaluation to gain a lot of speed right? I would venture to guess that your tree is full of misevaluated positions as a result (and as compared to a slower more paranoid full quies which in itself is guaranteed to generate silly scores like stopping when 2 pieces are forked!) The point is that I don't see this error as "worse" than 1000 other calculated compromised we all take. My strongest serial program had so many speed kludges and well considered compromises that adding a rare hash table collision to the heap would have been like a fly landing on an elephants back! >Also, I'd think you'd go insane if you lost a half-point every 30 games due to >something that was inexplicable. You'd spend a huge amount of time debugging, >and every time you find a hard bug you'd pass it off as this problem, and you >wouldn't be right every time. This is a good argument. I did say I'm gradually changing over the years! With a serial program, it's not a big problem, I can debug known problems quickly. But with a parallel program, it is a much bigger problem, because many bugs cannot be reproduced at will. I am very strict about making my programs completely deterministic because it makes debugging a trivial process. But this goes all to hell with a parallel program. But we have had no trouble at all with parallelism. It's almost an afterthought for us. The program is written to facilitate the parallel version but the serial program IS the parallel program, the only difference is which header file you include. >I'm willing to allow my program to make mistakes, but I'd really like to >understand them at least. > >It isn't clear that you'd lose a half point every 30 games though, it might be >every 30 years, which is a lot more acceptable. I just basically made up the example. I know that you make these same judgement calls. If you were completely concerned about absolute correctness you would throw out the hash tables or use them in a very limited way right? And your program is selective right? Didn't you know that selectivity will throw out a critical move once in a while? I have seen how fast your program is so I know you are a speed freak too! >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.