Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: What is the branching factor for this position?

Author: leonid

Date: 19:30:01 08/10/00

Go up one level in this thread


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.



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.