Computer Chess Club Archives


Search

Terms

Messages

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

Author: Robert Hyatt

Date: 21:18:21 08/11/00

Go up one level in this thread


On August 11, 2000 at 23:37:12, Tom Kerrigan wrote:

>On August 11, 2000 at 22:45:05, Robert Hyatt wrote:
>
>>On August 11, 2000 at 17:56:02, Tom Kerrigan wrote:
>>
>>>On August 11, 2000 at 15:49:57, Robert Hyatt wrote:
>>>
>>>>On August 11, 2000 at 13:48:22, Tom Kerrigan wrote:
>>>>
>>>>>On August 11, 2000 at 09:09:38, Robert Hyatt wrote:
>>>>>
>>>>>>On August 10, 2000 at 23:20:42, Tom Kerrigan wrote:
>>>>>>
>>>>>>>On August 10, 2000 at 21:46:24, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>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
>>>>>>>
>>>>>>>If your program has no check extension and no quiescence search, how is it any
>>>>>>>easier to debug?
>>>>>>>
>>>>>>>-Tom
>>>>>>
>>>>>>
>>>>>>It has less code to go wrong.  I started off writing my move generator and
>>>>>>nothing else.  I debugged that until I was sure it worked.  That is far
>>>>>>easier than writing the whole thing, then debugging several thousand lines
>>>>>>of new and untested code, all at one time.
>>>>>>
>>>>>>This is why the top-down approach became so popular years ago...
>>>>>
>>>>>Yes, I also wrote my move generator before anything else.
>>>>>
>>>>>But Lenoid has written an entire chess program. He simply refuses to put in
>>>>>extensions or qsearch.
>>>>>
>>>>>I think such a program would be harder to debug. Does it play God-awful moves
>>>>>because it has no qsearch, or is it due to some bug? Hard to tell.
>>>>>
>>>>>-Tom
>>>>
>>>>
>>>>I wouldn't argue with that statement at all.  Not having any q-search will lead
>>>>to many bogus PVs, obviously.  But once you have a reasonable search, a reason-
>>>>able q-search, and a simple eval(), you are set to test and debug for a long
>>>
>>>Right, Lenoid doesn't have a reasonable q-search.
>>>
>>>I believe that check extensions are also necessary to avoid horrible
>>>horizon-effect moves.
>>>
>>>-Tom
>>
>>
>>I don't think it is too hard to understand the horizon effect, and notice when
>>you see it in your PVs.  IE even search extensions don't eliminate this problem
>>so it is useful to become skilled at recognizing the problem anyway, because
>>it will happen no matter what you do (maybe less frequently, but less != 0).
>>
>>I am more concerned about the kind of bugs that cause more subtle and hard
>>to reproduce errors.  Horizon effects are easy to see (with experience).  A
>>legal move generator that misses the one enpassant way out of check is much
>>more difficult to catch.
>
>I never said that check extensions completely eliminate horizon-effect problems.
>
>But if you don't extend when in check, your program will just throw away its
>pieces to give check and only later realize that those pieces are useful...
>
>-Tom

It certainly happens, but at today's speeds, I don't think it would be a
critical shortcoming.  I ran on ICC when I first started the Crafty project,
with no extensions at all.  Good extensions are good.  Buggy extensions can
add more problems than they solve.

Same old argument, more code -> more bugs, and generally it is not a linear
relationship either.  I know how to spot horizon problems.  I don't know how
to spot problems where I failed to generate one key move out of 10M moves, or
where I made some other subtle programming error.  Extensions can hide or
obscure so many of those problems...  It is (to me) harder to try to answer
"is it a null move problem?  a hashing problem?  a search extension problem?
a pruning problem? a lazy eval problem?  Etc.  Eliminating that list, or at
least shortening it, can make the first few months more pleasant.



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.