Author: Vincent Diepeveen
Date: 06:18:55 04/07/02
Go up one level in this thread
On April 06, 2002 at 03:48:28, TEERAPONG TOVIRAT wrote:
>
>Hi,
>
>1)
>Should we let the Futility Margin be a constant value or variable?
>IMHO, it should be a variable that varies with
>1.material balance at root node.
>2.material ratio at current node.
>?
Don't use it simply. It's nonsense and makes
a program positional weaker. the frontier nodes are
important to get to a quiet position.
>2)
>Extended Futility Pruning method from Ernst Heinz's recommendation :
>....
>fscore=material_balance+razor margin
>if(!extend&&(depth==pre_pre_frontier)&&(fscore<=alpha)&&(...))
>depth=prefrontier
>fscore=material_balance+extd_fut_margin
>if(!extend&&(depth==pre_frontier)&&(fscore<=alpha))
>{score=fscore
> fprune=1
>}
Idem as above.
>....
>It's obvious that if the first if statement is true the second if must be true.
>Just curious to know why the author didn't avoid testing the second if?
>?
there is a huge difference between futility in the qsearch and
forward pruning. forward pruning is modifying the search tree,
and futility is modifying the scores for a position X, whereas
forward pruning doesn't necessarily do this.
Getting to a quiet position is something completely different
than forward pruning quiet positions.
>3)
>Some programs have an evaluation hashtable to store the score from
>evaluation(). I think we already have transposition table for this job.
>And nowaday, we can provide plenty of entries.The chance of collision in
>transposition table is not so significant. So,why?
>?
You do this if your evaluation is slow. Mine is slow, so i use it.
Yes i also store it in transposition table. I use 8 probes in transtable.
apart from that i have a seperated evaluatoin table. Remember that such
a table is like 300 clocks extra for every call to evaluating a position.
Because i have a huge transpositiontable with 8
probes chance is already small that a previously evaluated position is
not inside this transposition table. So biggest 'hit' i get from
this transpositiontable.
Nevertheless especially leaf nodes get overwritten easily, so
that's where an evaluation table with a different way to index
jumps in.
The number of true hits i get out of this eval table is not so big in fact,
but the total picture is important:
Suppose i would need n evaluations:
Suppose i get 50% out of transpositiontable (which is realistic number),
also checking of course the other side. that leafs 0.5 n calls to
evaluate() the position.
in evaluate then eval table hops in. the % of hits i get in evaluate
has nothing to do with n of course. it is just a % of 'total' evaluated
nodes. Here we see how well the transpositiontable already is doing
its job, because i get sometimes very low hitrates in evaltable. Sometimes
only 10%.
Nevertheless if i count from the search how big the chance is that a
position needs evaluation then the chance is only 0.4 or 40%
Storing an evaluation takes system time. i estimate 300 clocks or something
at modern hardware with DDR ram.
That means that if you get 10% hitrate, that if evaluation is like 3000
clocks or something, that you really don't want to store. In DIEP i don't
feel this of course. Evaluation is more near 200000 clocks than it is
near 3000 clocks.
In crafty a look like programs this sure isn't the case. It's more like
3000 clocks then and i bet most didn't measure hitrate.
>Thanks for any comment,
>Teerapong
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.