Alpha-beta inconsistencies

[Chua Kong Sian]

The current patchlevel 70 exhibit some undesirable alpha-beta
inconsistencies. Take a look at the following post output.

Your move is? Enter file name:

White 1:00 Black 1:00

- - R Q - K R -
B P - - - P - -
P - - P B - - -
- - - - - n - P
- p - P b - - p
p - - - - - p -
- - p - q p - -
- - - r - r k -

Your move is?
Your move is?
Your move is?
Move# 1 Target= 6000 Clock: 6000
2. -142 0 7620 d6d5 e4d3 e6f5 d3f5
3& -142 0 7897 d6d5 e4d3 e6f5
3+ -31 0 11104 e6f5 c2c4 c8c4 e4f5 d4d3 d1d3 c4h4 e2h5
3& 133 0 17297 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
d3c2 f5c2
3. 133 1 30227 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
d3c2 f5c2
4+ 228 1 39084 e6f5 e2c4
4- 220 4 98342 e6f5 e4f5 g8g7
4- 223 4 98560 g8g4
4- 223 4 99171 g8g5
4. 223 4 107422 g8g5
5- 35 5 126487 g8g5 h4g5 d8g5 f5d4 a7d4
5- 49 6 141692 g8g4 f1e1 g4g5
5& 149 11 265770 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2 d3c2 f5c2 d8b6 g1f1 b6e3 d1d5
5. 149 15 356544 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2 d3c2 f5c2 d8b6 g1f1 b6e3 d1d5
6& 150 21 510973 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2
6. 150 33 760747 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2
7. 150 60 1398467 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2
1. ... e6f5
Gen 5528171 Node 1398467 Tree 860 Eval 62870 Rate 23307 EC 37502/24315 RS hi 0 lo 2
Hin/Hout/Tcol/Coll/Fin/Fout = 42479/11016/0/0/0/0
My move is: e6f5

Your move is?
==========================================================================

Take a look at depth=4. First the search fail-high with a score of 228
points. The value of beta at this point is 223 (not shown, but I did
print it out during some other test runs). What happens next is that a
lower bound value of beta+1=224 is stored in the hash table. The search
is now restarted with a window of (-9999, 9999).

However, at ply=1, the hashtable is probed and the lowerbound value of
224 is found to which alpha is set. Now a search of the position
suddenly yields a score of 220, which is less than 224. So an
alpha-beta inconsistency has occurred at ply=1 and the final move picked
for depth=4 is Rg5 which is absolutely wrong.

The simplest way of solving this problem is not to probe the table at
ply==1 (which is what is done with pl68). I tried this and here is what
I obtained.

White 1:00 Black 1:00

- - R Q - K R -
B P - - - P - -
P - - P B - - -
- - - - - n - P
- p - P b - - p
p - - - - - p -
- - p - q p - -
- - - r - r k -

Your move is?
Your move is?
Your move is?
Move# 1 Target= 6000 Clock: 6000
2. -142 0 7620 d6d5 e4d3 e6f5 d3f5
3& -142 0 7897 d6d5 e4d3 e6f5
3+ -31 0 11104 e6f5 c2c4 c8c4 e4f5 d4d3 d1d3 c4h4 e2h5
3& 133 1 18072 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
d3c2 f5c2
3. 133 1 30066 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
d3c2 f5c2
4+ 228 2 38929 e6f5 e2c4
4& 224 6 105875 e6f5 e4f5 g8g7
4. 224 6 115636 e6f5 e4f5 g8g7
5& 125 10 183693 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2 d3c2 f5c2
5. 125 14 257775 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2 d3c2 f5c2
6& 126 22 384699 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2
6. 126 36 603067 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2
7. 126 60 1014040 e6f5 e4f5 g8g3 f2g3 d4d3 e2f2 a7f2 f1f2
c8c2 f2c2
1. ... e6f5
Gen 4349666 Node 1014040 Tree 928 Eval 50819 Rate 16900 EC 30723/19063 RS hi 0 lo 2
Hin/Hout/Tcol/Coll/Fin/Fout = 35324/9925/0/0/0/0
My move is: e6f5

Your move is?

==========================================================================

In this case, the search is able to respect the (-9999, 9999) window
at ply=1 and no alpha-beta inconsistencies at ply=1 occurs.

Kong Sian

[Chua Kong Sian]

To implement the change in my previous post, edit search.c and goto
line 755 or thereabouts. Change

if (flag.hash)

to

if (flag.hash && ply > 1)

Kong Sian