Author: Christophe Theron
Date: 14:14:37 10/30/03
Go up one level in this thread
On October 30, 2003 at 13:04:02, Tord Romstad wrote:
>On October 30, 2003 at 12:45:47, Christophe Theron wrote:
>
>>On October 30, 2003 at 12:43:04, José Carlos wrote:
>>
>>> After every iteration I print in my log file something like:
>>>
>>> Branching factor:
>>> - This iteration = Total Nodes / Nodes Last Iteration
>>> - Acumulated: pow(Total Nodes,1.0 / Depth)
>>>
>>> With this measure, I'm finding that my program has huges BF's (per iterartion)
>>>in the first nodes, that go down to <= 3 after 5 iterations or so. But the
>>>acumulated has a slow reducing behaviour, going to <= 3 after at least 12 plies.
>>> I'm still working on understanding it :)
>>>
>>> José C.
>>
>>
>>
>>The QSearch is maybe a part of the reason.
>
>I think so, too.
>
>>The percentage of QSearch nodes in the first iterations is higher than in the
>>deeper iterations.
>>
>>At least that is my experience.
>
>I understand perfectly well if you don't want to answer this question,
>but still:
>
>How do you cope with this problem (high branching factor in the first
>few plies) in Chess Tiger? Because your program runs on slow PalmOS units,
>I suppose you must have some tricks to make the search more efficient
>at low search depths. I am considering to make a PalmOS version of my
>own program (a non-trivial task, because my current data structures are
>too big to fit in such limited memory), therefore I would be very
>interested to learn how you do it.
>
>Tord
I have a special system to deal with this, which is a legacy of my very old 16
bits version.
But in general your problem will be to make the QSearch as small as possible
while keeping a good tactical accuracy. This can be considered as 30% of the
work involved in creating a competitive chess program.
Christophe
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.