Author: leonid
Date: 16:43:03 08/11/00
Go up one level in this thread
On August 10, 2000 at 23:06:16, Robert Hyatt wrote: >On August 10, 2000 at 22:30:01, leonid wrote: > >>On August 10, 2000 at 21:46:24, Robert Hyatt wrote: >> >>>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. >> >>Agree! >> >>Leonid. > > >Just don't get carried away, unless you are _sure_ (which is very unlikely) >that your data structures/algorithms won't ever change. Most of us do several >total-rewrites as we develop these things. If you spend a lot of time making >the best 0x88 move generator you can make, then decide to switch to something >else because it fits better with some new ideas you have, all that old code >(and the effort included in it) will be tossed out. Actually I am very close to the third part of my programming, only will try to search for bugs for some time. Had too many rewritten code after my last speeding to feel me secure. After each new version of brute force part, all other versions that do the search (probably their name is selective searchers) are redone. And sometime there could be not only some new bugs. Yesterday I found two old one. Trouble with everything after writing mate solver (if somebody ever start this way) is that second part of chess program is very difficult to verify. Before, after each speeding of my mate solver, I was loosing somewhere few weeks with verifications. Few hundred (if not thousand) of positions was enough to be pretty sure about solver itself and move generator that worked for him. Now, in my second part, all the verification was slow and imperfect. Search of big number of positions by brute force, at fixed depth, by few programs was my way to work. Sometime verification done by seeing responses for the same positions with two distinct version of brute force searcher in the same program. For instance, comparing suspect solution by "normal" part of my program (that do brute force search) and other part of my program that do (brute force search) it using homogeneous plys structure. Comparing solutions with other big chess programs was a pain. Few programs even have brute force as such. Immediatelly after this words came all kind of surprises like "extensions", not fixed depth and so like. Search in many programs just can explode with endless time consumed by extensions. Well, anyway, if some really dramatic I will not find in two next weeks, chances are that my second part is completely done. I speak so long because I am almost sure that you will find that all your writing was done in very similar way. Leonid.
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.