Author: Robert Hyatt
Date: 18:46:24 08/10/00
Go up one level in this thread
On August 10, 2000 at 20:45:24, leonid wrote: >On August 10, 2000 at 19:05:43, Tom Kerrigan wrote: > >>On August 10, 2000 at 18:46:07, leonid wrote: >> >>>On August 10, 2000 at 18:17:12, Tom Kerrigan wrote: >>> >>>>On August 10, 2000 at 17:42:24, leonid wrote: >>>> >>>>>On August 10, 2000 at 16:51:08, Tom Kerrigan wrote: >>>>> >>>>>>On August 10, 2000 at 15:45:06, leonid wrote: >>>>>> >>>>>>>On August 10, 2000 at 13:58:22, Tom Kerrigan wrote: >>>>>>> >>>>>>>>On August 10, 2000 at 07:54:32, leonid wrote: >>>>>>>> >>>>>>>>>On August 09, 2000 at 21:44:38, Tom Kerrigan wrote: >>>>>>>>> >>>>>>>>>>On August 09, 2000 at 17:32:48, leonid wrote: >>>>>>>>>> >>>>>>>>>>>On August 09, 2000 at 17:04:37, Tom Kerrigan wrote: >>>>>>>>>>> >>>>>>>>>>>>On August 09, 2000 at 15:59:24, leonid wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>I don't recall Ed ever calling his search brute force. >>>>>>>>>>>>>> >>>>>>>>>>>>>>-Tom >>>>>>>>>>>>> >>>>>>>>>>>>>If it is so, now I see why my branching factor is so miserable. >>>>>>>>>>>>> >>>>>>>>>>>>>I asked above question when I tried to solve this position by brute force. For >>>>>>>>>>>>>black side I looked up to 10 plys deep and it took already 12 min 17 sec. Move >>>>>>>>>>>>>was wrong. Black knight goes to the position e2. And for finding right move I >>>>>>>>>>>>>must go to the next 12 plys search. But this could take some next 6 hours. This >>>>>>>>>>>>>is how my old question about branching factor came to me. It prohibit to my >>>>>>>>>>>>>program to see very rapidly and reach far distance. >>>>>>>>>>>> >>>>>>>>>>>>You're the only person in the entire world who does these "brute force" >>>>>>>>>>>>searches. >>>>>>>>>>>> >>>>>>>>>>>>-Tom >>>>>>>>>>> >>>>>>>>>>>When you want to know if your basic speed is the right one, only brute force >>>>>>>>>>>search could say you so. This I remember from writing my program for finding >>>>>>>>>> >>>>>>>>>>I don't know what basic speed means, but I'm sure that there isn't a right one. >>>>>>>>>>And a fixed-depth brute force search with no extensions and no quiescence search >>>>>>>>>>won't tell you anything useful. >>>>>>>>>> >>>>>>>>>>-Tom >>>>>>>>> >>>>>>>>>Tom, if you compare two programs that do its search, but not by brute force, you >>>>>>>>>actually compare "pruning technics" for both of them. But how much program with >>>>>>>>>good pruning technics still miss from its potential, you will find by seeing its >>>>>>>>>brute force speed only. >>>>>>>> >>>>>>>>What potential? Presumably the pruning techniques are increasing the program's >>>>>>>>potential, otherwise the author wouldn't use them. >>>>>>>> >>>>>>>>-Tom >>>>>>> >>>>>>>The same pruning technics, in two programs that have different brute force base, >>>>>>>winner will be program with best brute force speed. But by the same talken, it >>>>>>>could be said that program with best pruning technincs could be speeded even >>>>>>>more by speeding its brute force part. Sometime this brute force speeding will >>>>>>>simply forgotten when program already shine with its advanced pruning >>>>>>>capability. >>>>>> >>>>>>The speed of a forward-pruning program can be tested (and improved) just as >>>>>>easily as any other program. >>>>>> >>>>>>My point is that your "brute force" searches are extremely stupid and there's no >>>>>>reason for anyone to do them ever. >>>>>> >>>>>>-Tom >>>>> >>>>>Everybody can choose its own way. In the first part of my program I did exectly >>>>>like you said, pruning technics first and brute force second. My second part I >>>>>go opposit way. Experience say me that this way is logical. For you entire game >>>>>start and end with one part. Here we are different. >>>> >>>>I made a copy of my program that does your brute force searches, i.e., no check >>>>extension, no quiescence search, and no null move. I called it "Stupid." >>>> >>>>I played a match between Stupid and my program. >>>> >>>>Stupid lost 20 games in a row. It usually got mated around move 30. Once in a >>>>while it would last for 50-60 moves. >>>> >>>>So basically, you can add 3 things that are well-understood and that everybody >>>>has and you can immediately increase your program's strength by 400+ points, or >>>>you can continue down your brute force path and never have a strong program. >>>> >>>>-Tom >>> >>>And now find your own program that do brute force worst that actual one. After >>>putting everything that you took off your first program into both of them, find >>>what is best. Now, you see my point. >>> >>>I not diminish importance of pruning and everything else in the program - not at >>>all. Too early inclusion of all those final additions can obscure the fact that >>>its initial and most important part stays weak and unaccomplished. >> >>To make a good program, you must constantly improve everything. And that means >>that you must have everything in it before you start improving it. >> >>Let's say you work for Ferrari and you want to build the best car ever. When you >>come up with the prototype, do you drive it around on its wheel rims because you >>want to make sure the car is perfect before you try it with tires? That would be >>stupid, and so is working for years on a chess program that doesn't do check >>extensions or quiescence searchs. >> >>-Tom > >For somebody that want to write its chess program at any price, your way is the >right one. For somebody who want to write entire program only when it will have >the chance to do the best one, is my way to go. > >Leonid. Either way will work. your way is the way suggested by software engineering. And your way will have less debugging. Your way will make it hard to evaluate chess "skill" of course, as the program will be incomplete for a long time, and it will make some stupid mistakes. Doing the whole thing up front will _also_ make some stupid mistakes due to the bugs in the more complicated code.
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.