Well, let's say is something in between... First time I implemented this, I overlooked the wiki page, and I wrongly updated bestScore only when score was already above alpha, and that produced a very bad effect of backing up inconsistent mates to upper plies. Then I found a post that said that in FS bestscore could not be initialized to -INF, but already alpha, since returning values > beta you could propagate scores outside bounds and changed implementation... Thinking about it, it's true, parent will never improve alpha, so score will go unnoticed.Sven Schüle wrote: This is almost pure fail-hard The only deviation was already mentioned by Michael: you return "score" instead of "beta" in case of a beta cutoff (and additionally you possibly return a mate or draw score even if it is outside the alpha-beta window). But this won't make any difference in my opinion since the parent will simply not improve his "alpha" anyway, so the return value goes fully unnoticed. Even if you use the same algorithm at root I think it should not matter. But you can try whether I am right or wrong by replacing the "return score" by "return beta", of course
Sven
Now I did a true FS, QS and IID disabled, active only "hash, killers, search, evaluate" and I can see (at least I think I can see) what is happening there (the number aside ">" sign is the number of FH, window is opened with powers of two, starting with 1cp):
Code: Select all
--------------------------------------------------------------------------------
00:00:01.302 15 Bd1-c2 16.5M +6.00 1. Bd1-c2 Kh1-g1
2. Bc2-b1 Kg1-f1
3. Bb1-a2 Kf1-g1
4. Ba2-b1 Kg1-f1
5. Bb1-a2 Kf1-g1
6. Ba2-b3 Kg1-f1
7. Bb3-d1 Kf1-g1
8. Bd1-c2
00:00:02.119 15 Bd1-e2 16.3M +MATE25 > 1
00:00:02.120 15 Bd1-e2 4.6M +MATE24 > 2
00:00:02.121 15 Bd1-e2 7.9M +MATE23 > 3
00:00:02.130 15 Bd1-e2 13.0M +MATE21 > 4
00:00:02.131 15 Bd1-e2 14.0M +MATE17 > 5
00:00:02.136 15 Bd1-e2 11.2M +6.00 1. Bd1-e2 Kh1-g1
2. Be2-d1 Kg1-f1
3. Bd1-c2 Kf1-g1
4. Bc2-b1 Kg1-f1
5. Bb1-a2 Kf1-g1
6. Ba2-b1 Kg1-f1
7. Bb1-a2 Kf1-g1
8. Ba2-b1
--------------------------------------------------------------------------------
00:00:02.996 16 Bd1-e2 10.8M +MATE40 > 1
00:00:03.016 16 Bd1-e2 9.6M +MATE39 > 2
00:00:03.017 16 Bd1-e2 +MATE38 > 3
00:00:03.022 16 Bd1-e2 6.3M +MATE36 > 4
00:00:03.035 16 Bd1-e2 9.2M +MATE32 > 5
00:00:03.235 16 Bd1-e2 10.5M +MATE24 > 6
00:00:03.249 16 Bd1-e2 9.4M +6.00 1. Bd1-e2 Kh1-g1
2. Be2-d1 Kg1-f1
3. Bd1-c2 Kf1-g1
4. Bc2-b1 Kg1-f1
5. Bb1-a2 Kf1-g1
6. Ba2-b1 Kg1-f1
7. Bb1-a2 Kf1-g1
8. Ba2-b3 Kg1-f1
--------------------------------------------------------------------------------
00:00:08.211 17 Bd1-e2 16.4M +MATE69 > 1
00:00:08.212 17 Bd1-e2 319.0K +MATE68 > 2
00:00:08.213 17 Bd1-e2 351.0K +MATE67 > 3
00:00:08.215 17 Bd1-e2 351.0K +MATE65 > 4
00:00:08.220 17 Bd1-e2 13.0M +MATE61 > 5
00:00:08.292 17 Bd1-e2 16.4M +MATE53 > 6
00:00:08.312 17 Bd1-e2 16.2M +MATE37 > 7
00:00:08.438 17 Bd1-e2 16.8M +6.00 1. Bd1-e2 Kh1-g1
2. Be2-d1
--------------------------------------------------------------------------------
00:00:20.114 18 Bd1-e2 9.9M +MATE156 > 1
00:00:20.203 18 Bd1-e2 9.2M +MATE155 > 2
00:00:20.206 18 Bd1-e2 4.2M +MATE154 > 3
00:00:20.207 18 Bd1-e2 +MATE152 > 4
00:00:20.227 18 Bd1-e2 8.3M +MATE148 > 5
00:00:20.235 18 Bd1-e2 8.3M +MATE140 > 6
00:00:20.913 18 Bd1-e2 9.8M +MATE124 > 7
00:00:25.632 18 Bd1-e2 9.8M +MATE92 > 8
00:00:26.515 18 Bd1-e2 9.4M +MATE28 > 9
00:00:27.029 18 Bd1-e2 9.7M +6.00 1. Bd1-e2 Kh1-g1
2. Be2-d1 Kg1-f1
3. Bd1-c2 Kf1-g1
4. Bc2-b1 Kg1-f1
5. Bb1-a2 Kf1-g1
6. Ba2-b1 Kg1-f1
7. Bb1-a2 Kf1-g1
8. Ba2-b3 Kg1-f1
9. Bb3-d1 Kf1-g1
--------------------------------------------------------------------------------
00:00:57.302 19 Bd1-e2 15.3M +MATE264 > 1
00:00:57.315 19 Bd1-e2 13.5M +MATE263 > 2
00:00:57.321 19 Bd1-e2 15.3M +MATE262 > 3
00:00:57.322 19 Bd1-e2 3.4M +MATE260 > 4
00:00:57.323 19 Bd1-e2 6.3M +MATE256 > 5
00:00:57.350 19 Bd1-e2 15.4M +MATE248 > 6
00:00:57.377 19 Bd1-e2 14.9M +MATE232 > 7
00:01:25.478 19 Bd1-e2 15.7M +MATE200 > 8
00:01:28.720 19 Bd1-e2 16.1M +MATE136 > 9
00:01:35.279 19 Bd1-e2 15.8M +6.00 1. Bd1-e2 Kh1-g1
2. Be2-d1 Kg1-f1
3. Bd1-c2 Kf1-g1
4. Bc2-b1 Kg1-f1
5. Bb1-a2 Kf1-g1
6. Ba2-b1 Kg1-f1
7. Bb1-a2 Kf1-g1
8. Ba2-b3 Kg1-f1
9. Bb3-d1 Kf1-g1
10. Bd1-c2
--------------------------------------------------------------------------------
00:15:06.642 20 Bd1-e2 8.9M +299.93 > 1
00:15:28.677 20 Bd1-e2 9.2M +MATE76 > 2
00:15:30.529 20 Bd1-e2 9.3M +MATE75 > 3
00:15:30.565 20 Bd1-e2 9.1M +MATE73 > 4
00:15:30.569 20 Bd1-e2 7.5M +MATE69 > 5
00:15:30.688 20 Bd1-e2 8.9M +MATE61 > 6
00:15:30.791 20 Bd1-e2 9.2M +MATE45 > 7
00:17:51.152 20 Bd1-e2 9.3M +6.00 1. Bd1-e2 Kh1-g2
2. Be2-d1 Kg2-f1
3. Bd1-c2 Kf1-g1
4. Bc2-b1 Kg1-f1
5. Bb1-a2 Kf1-g1
6. Ba2-b1 Kg1-f1
7. Bb1-a2 Kf1-g1
8. Ba2-b3 Kg1-f1
9. Bb3-d1 Kf1-g1
10. Bd1-c2 Kg1-f1
00:20:31.284 20 Kd6-e5 9.2M +MATE13 > 1
00:21:40.464 20 Kd6-e5 9.2M +MATE12 > 2
00:21:57.154 20 Kd6-e5 9.3M +MATE11 > 3
00:23:11.766 20 Kd6-e5 9.2M +6.00 1. Kd6-e5 Kh1-g2
2. Bd1-c2 Kg2-f1
3. Bc2-b1 Kf1-g1
4. Bb1-a2 Kg1-f1
5. Ba2-b1 Kf1-g1
6. Bb1-a2 Kg1-f1
7. Ba2-b3 Kf1-g1
8. Bb3-d1 Kg1-f1
9. Bd1-c2 Kf1-g1
10. Bc2-b1 Kg1-f1
Q1) How a program can fail-high with a score like "mate in 25", that is _50_ plies, if it's "still" at ply 15?
A1) Hashtable hits! Debugging my code I saw HT is filled initially with few mate scores (something like mate in 3, because black doesn't move out of the corner, doesn't take a piece etc..., all these positions are analyzed and eventually stored in hashtable). Something like recursion, at some point, the program will enter a position say at ply 12, query the hashtable that is returning a score of mate in 3 and make the correction, that means mate in 9. That position can be hit on another part of the tree at ply 12 too, so it keep correcting the score until it reaches that mate in 25... These are NOT forced mates, are like "artificial" mates... And black can escape those artificial mates so root gets a score of 6.00.
Q2) Is that 6.00 score an exact score after 5 FH with scores like MATE17?
A2) Yes! _WE_ know this score is really a MATE11!!, the program still has not the depth to see it clearly. That score simply means black CAN be mated in at most 17 moves, but at ply 15 it cannot see a way to force a mate in less moves. In other means, the program is saying "if black is smart, he is safe for at most 17 moves..."
Q3) Other iterations?
A3) Well, I think hasthtable becomes full of mate scores eveywhere...And the positions stored gets stored with scores biggers and biggers... It's like a dog chasing its tail...
Q4) Iteration 20 finds a mate in 11, but then still scores 6.00.
A4) Read A2! It still misses one ply to mate (well, two plies effectively since _my_ evaluate has no idea of what mate is, and QS is disabled so mate is returned by the black site to move at ply 22).
Q5) Mate in 264??? That's funny!
A5) Yes it is... But looking at first FH of iteration 20 the score is 299.93, outside my mate scores (30000, where mate is 32000), that means a mate in 1000+ moves )) Quite easy to understand.... My program annouced mate in 1000 moves... oh yeah... It could be a fright for every top program!!!
I think that's all... If what I wrote is true (please someone confirm that!) I know there's no bug and the search works properly. It could be useful if someone else could disable extensions blah blah blah and test if his/her program behaves the same way.
Program is still running, after 50 mins still didn't go to ply 21...
Let me know....
Natl.