Author: Dieter Buerssner
Date: 03:26:28 03/19/05
Go up one level in this thread
On March 18, 2005 at 17:26:03, Ross Boyd wrote:
>However, with TRACE I have become envious of other engine's PV lengths... (it
>must be a male thing, ha ha)
:-) Hey, my engine just at the moment when I read this, spit out:
4523931 4.344 1.40 19. 49.Kd2 Ke8 50.Ke3 Kf7 51.Kf4 Kf8 52.Ke4 Ke8
53.Kd3 Kd7 54.Ke2 Ke8 55.Kd2 Kf7 56.Kc2 Ke8
57.f7+ Kxf7 58.Kc3 Ke8 59.a5 bxa5 60.Kc4 Kf7
61.Kc5 Ke8 62.Kd6 Kf7 63.Kc7 Ke8 64.Kc6 Kf7
65.Kb6 Ke8 66.Kxa6 Kf7 67.Ka7 Ke8 68.Kb7 Kf7
69.Kc7 Ke8 70.Kd6 Kf7 71.Kc5 Ke8 72.Kb5 Kf7
73.Kc4 Ke8 74.Kc5 Kf7 75.Kd6 Ke8 76.Kc6 a4
77.Kb6 Kf7 78.Ka6 a3 79.Kb5 Ke8 80.Kb4 Kf7
81.Kc3 Ke8 82.Kd2 Kf7 83.Ke2 Ke8 84.Kf3 Kf7
85.Kf4 Ke8 86.Kg5 Kf7 87.Kh6 Ke8 88.Kxh5 a2
89.Kg5 a1=Q 90.h5
>It may be the replacement scheme. This particular position has a tendency to
>generate TT 'log-jams' where previous depth-preferred entries block out newer
>entries and therefore makes the search a little bit 'stubborn'... if you know
>what I mean. Try always-overwrite temporarily for a quick test.
I think in general a replace always policy will be better, than a depth
preferred, even when it does not sound logical. Fabien mentioned, that Fruit can
store two scores/bounds for each position. I also experimented with this, but it
performed worse (in games especially, not so much in test positions) than the
normal scheme. I did not understand why, perhaps the implementation was buggy. I
tried hard to find any bugs, but did not see anything.
With my normal scheme (replace always, but also some space reserved for depth
preferred entries), Yace will solve Fine 70 in practically no time, when it uses
only 1000 hash entries. But I agree, that one should not tune hashing on Fine
70.
Regards,
Dieter
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.