Author: Robert Hyatt
Date: 06:12:12 04/25/00
Go up one level in this thread
On April 25, 2000 at 00:50:50, Tom Kerrigan wrote: >On April 24, 2000 at 22:13:10, Bruce Moreland wrote: > >>On April 24, 2000 at 18:49:04, Tom Kerrigan wrote: >> >>>On April 24, 2000 at 15:56:37, Dann Corbit wrote: >>> >>>>On April 24, 2000 at 15:43:24, Tom Kerrigan wrote: >>>>[snip] >>>>>Here's my question. If pondering=off cripples Crafty so badly to the point that >>>>>Bob Hyatt has to write dozens of posts about it, why doesn't he just do >>>>>something to fix it? I mean, surely the time spent writing all those posts could >>>>>have been put to better use. >>>> >>>>That makes a great deal of sense if Dr. Hyatt were writing crafty to make people >>>>happy who want to play engine verses engine matches on a single machine. >>>>However, he does not play it that way and it is contrary to his purposes. >>>> >>>>Do you alter your programs to make them do what others wish even when it does >>>>not coincide with your desires? >>> >>>Yes. >>> >>>-Tom >> >>If your point is that Bob should do this or that, I think that Bob should be the >>one who decides what Bob does. It's great to suggest improvements in >>functionality or support, but if Bob wants to do it his own way, that's fine. > >Decisions are influenced by your surroundings. > >Right now, Bob is surrounded by people who do matches between Crafty and ___ >with no pondering. Consequently, Bob has to do a tremendous amount of damage >control. Here are the options, as I see them: > >1) Continue to waste time by doing massive damage control > >2) Simply remove the ponder switch from Crafty, so Crafty can't be crippled > >3) Un-cripple Crafty > >Personally, I would not like to _continually_ make excuses for my program, i.e., >option 1. I think option 2 is a hack, but still better than option 1. >Personally, I would go with option 3. > >I don't really see what the problem is with option 3. If Crafty is using too >much time in the opening and middlegame, just make it use less time. Multiply >some number by 75% or whatever. It may not be a "fine tuned" solution, but at >least the program won't lose all its games. > >-Tom Once you add some sophistication to your time control logic, you will see that the above is a very 'superficial' suggestion. Base time allocation is but one part of the problem. How much time can you use (extra time) when you get a positional fail-low, not a material one? How much extra time can you use on a fail low for a single pawn? For a piece? What if you do a 12 ply search, and the first 11 plies show you winning a pawn. At depth=12, after the first move, you discover that move doesn't win that pawn. How much extra time do you use there to see if the pawn win was real, or just a deep tactical plan by your opponent that made the pawn a "phantom"... These are serious decisions with serious repercussions. It isn't a matter of simply saying target=target*.75. At least in my program it isn't. Timing is interwoven with other decisions. Timing is _not_ trivial. My "rules" have taken years to reach a point where I consider them to be reasonable. If yours were written in a couple of nights, then they might be easy to change. Mine were not...
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.