H.G.Muller wrote:The changes should not be relevant for the strength. I think the first change only was for saving some characters in the engine routine, and I decided to put in the name printing just in case there were problems reported, so that I could find out which version exactly it was.
The 4.8m version handles checkmates a bit more concisely: at the expense of 1 extra character it is now guaranteed to always go for the fastest mate, where previous versions stopped deepening when they found any mate. This led to somewhat chaotic play in, e.g. KRK. But I really never saw uMax miss a mate because of it, so I assume there is no strength difference.
Thanks for the info!
H.G.Muller wrote:The bug is more of a problem. It does not seem to reproduce here, when I paste the position and run it. After 8 min on a 1GHz Athlon XP uMax finishes the 11th iteration and comes with a move (it switches to Bc4). This is a bit suspect, though, as I made also a version that prints every million notes the branch it is searching, and it came with another move at d=11 (Ra1). uMax is supposed to be completely deterministic (perhaps except for the decision if ait should do yet another iteration, which depends on clock jitter. But at the same depth it should always have the same move at the same depth.
What hash size did you use? Perhaps that could have an effect.
I used the default hash for it, which is around 100MB IIRC.
H.G.Muller wrote:Ever since I added the KeepHash option, uMax once in a while sinks into a very long thinking, forfeiting the game on time. If I play 1-minute games, every 50 games or so suddenly a move can take 5 minutes! This especially occurs in positions where the King is suddenly bared, or when the engines start repeating positions. But eventually it always returned a move. So I did not cconsider it a bug, just a bad judgement to start an iteration that would take way too long, caused by the unlucky circumstance that all previous iterations were satisfied from the hash in near-zero time, creating athe wrong impression that there was time for another one. Better time control (allowing interrupting of iterations) would fix this, but would be counterproductive for the goal of uMax, as the problem occurs so infrequently that there is at most perhaps only 5 Elo to gain by fixing it. And I cannot fix it with less than 5 characters.
I added the debug excerpt below and the full game.
BTW I am not so sure if it really happens infrequently by definition.
So far it happened in 3 out of 48 games in RWBC at 40/15 games.
H.G.Muller wrote:Fairy-Max shows similar behavior in Gothic Chess. But there it does not seem to come with a move there eventually, not even after 2 hours (in a 40/1' game!). So the engine process hangs, even after WinBoard has exited, which is very bad. And I discovered that the memory footprint reduced to only 100kB or so, with 128MB, while it is still using full CPU. So it cannot be doing a normal search, but must be stuck in some loop with only a small number of nodes probed. But I never succeded in reproducing such behavior starting from the same position. So it seems to be associated with hash-table contents from previous moves. But the game history is stored in the hash, so I clearing it between moves is not an option, or uMax would overlook all rep-draws, and no longer win any game at all.
I am not sure the problem is the same in Fairy-Max and micro-Max. As I said, with micro-Max I have never seen it failing to produce a move eventually. I am also not sure how the engine process can hang after WinBoard calls the flag and exits. I looked into the WinBoard code, and it is supposed to send kill signals to the engine processes before exiting. If engine processes survive kill signals, this is to be considered a serious OS bug...
Considering the unreliability of the kill mechanism, the best I can do at the moment is to make sure the engine quites by itself, by testing at a critical point that it cannot avoid if time is up, and resign and exit if that happens. Then at least it cannot hang. Such a modification I would not consider part of the engine, as resigning can never contribiute to playing strength, and the characters would count as part of the WB interface.
At least MicroMax doesn't hang here even after it loses on time.
There are some programs though which really can hang even after
WB tried to kill the processes. For those 'we' use a free commandline tool
which does a hard kill on those processes. It is called PV and is an
additional tool for a free process viewer called PRcView.
http://www.teamcti.com/pview/prcview.htm
(There are only a very few which need this and - from the top programs
it is only ProDeo as WB program.)
- Code: Select all
1315582 >first : time 22845
1315582 >first : otim 26802
1315582 >first : e8d8
1315592 <second:
1315632 <first : -1 -2 3136 4815346 g7g6
1315632 <first : 0 -37 3136 4815347 g7g6
1315632 <first : -1 71 0 1 f3d4
1315632 <first : 0 37 0 2 f3d4
1315632 <first : 1 37 0 3 b1a1
1315632 <first : 2 31 0 104 b1b2
1315632 <first : 3 30 1 1163 f3h4
1315652 <first : 4 30 1 4206 f3h4
1315672 <first : 5 30 8 25716 f3h4
1315752 <first : 6 30 15 53579 f3h4
1316934 <first : 7 24 133 518018 f1e1
1323994 <first : 8 24 839 3312419 c4b3
1333087 <first : 9 24 1749 6956924 c4b3
1333087 <first : move c4b3
Interrupting second
1333087 >second: time 26802
1333087 >second: otim 21093
1333087 >second: Bb3
1333107 <second: _|_|_|r|_|_|k|_|8
1333107 <second: _|q|_|_|r|p|p|_|7
1333107 <second: _|_|n|b|_|n|_|p|6
1333107 <second: _|_|p|_|_|P|_|_|5
1333107 <second: P|p|_|p|_|_|_|_|4
1333107 <second: _|B|_|P|_|N|_|P|3
1333107 <second: _|_|_|B|_|P|P|_|2
1333107 <second: _|R|Q|_|_|R|K|_|1
1333107 <second: a|b|c|d|e|f|g|h|
1333107 <second: FEN: 3r2k1/1q2rpp1/2nb1n1p/2p2P2/Pp1p4/1B1P1N1P/3B1PP1/1RQ2RK1 b - - 66 33
1333107 <second:
1333107 <second: STATUS: USERMOVE PROCESSED, BEGINNING MAIN THINKING
1333127 <second:
1333127 <second: STATUS: ALLOCATED: 17868 MS
1333127 <second: 2 73 0 50 34... Re2 35. Bc4 Ne5
1333127 <second: 2 75 0 499 34... Ne5 35. Nxe5
1333127 <second: 2 75 0 519 34... Ne5 35. Nxe5
1333127 <second: 3 75 0 763 34... Ne5 35. Nxe5 Rxe5
1333127 <second: 3 75 1 1793 34... Ne5 35. Nxe5 Rxe5
1333127 <second: 4 71 1 2936 34... Ne5 35. Nxe5 Rxe5 36. g4
1333147 <second: 4 71 3 7794 34... Ne5 35. Nxe5 Rxe5 36. g4
1333167 <second: 5 75 5 11475 34... Ne5 35. Nxe5 Rxe5 36. g4 Qf3
1333227 <second: 5 75 11 37623 34... Ne5 35. Nxe5 Rxe5 36. g4 Qf3
1333258 <second: 6 72 13 45950 34... Ne5 35. Nxe5 Rxe5 36. g4 Qf3 37. Qc4
1333598 <second: 6 72 48 156582 34... Ne5 35. Nxe5 Rxe5 36. g4 Qf3 37. Qc4
1333668 <second: 7 68 56 185545 34... Ne5 35. Nxe5 Rxe5 36. f4 Re2 37. Rf2 Rxf2
1335341 <second: 7 68 222 871820 34... Ne5 35. Nxe5 Rxe5 36. f4 Re2 37. Rf2 Rxf2
1335551 <second: 8 64 243 950065 34... Ne5 35. Nxe5 Rxe5 36. f4 Re2 37. Rf3 Kh8 38. Bc4
1336973 <second: 8 67 383 1457861 34... Re2 35. Qc4 Rde8 36. Bd1 R2e7 37. Bc2 Ne5 38. Nxe5
1341569 <second: 8 67 846 3045419 34... Re2 35. Qc4 Rde8 36. Bd1 R2e7 37. Bc2 Ne5 38. Nxe5
1348960 <second: 9 65 1585 6193370 34... Re2 35. Bc4 Rf8 36. Qd1 Re7 37. g4 Qa8 38. Rc1 Qa5
1349851 <second: 9 66 1674 6554382 34... Ne5 35. Nxe5 Rxe5 36. f4 Re2 37. Rf3 Qa8 38. Kh1 Kh8
1350983 <second: STATUS: EARLY ABORT: USING PV FROM DEPTH: 8
1350983 <second:
1351053 <second: 8 67 1794 6982620 34... Re2 35. Qc4 Rde8 36. Bd1 R2e7 37. Bc2 Ne5 38. Nxe5
1351053 <second: Nodes: 6982620 QNodes: 5742409 NPS: 390614
1351053 <second: TTHits: 247567 H/N: 19.9617% PawnTT: 2200735 P/E: 38.3242%
1351053 <second:
1351053 <second: _|_|_|r|_|_|k|_|8
1351053 <second: _|q|_|_|_|p|p|_|7
1351053 <second: _|_|n|b|_|n|_|p|6
1351053 <second: _|_|p|_|_|P|_|_|5
1351053 <second: P|p|_|p|_|_|_|_|4
1351053 <second: _|B|_|P|_|N|_|P|3
1351053 <second: _|_|_|B|r|P|P|_|2
1351053 <second: _|R|Q|_|_|R|K|_|1
1351053 <second: a|b|c|d|e|f|g|h|
1351053 <second: FEN: 3r2k1/1q3pp1/2nb1n1p/2p2P2/Pp1p4/1B1P1N1P/3BrPP1/1RQ2RK1 w - - 68 34
1351053 <second:
1351053 <second: STATUS: WHITE CLOCK(opp): 03:13 BLACK CLOCK(engine): 04:11
1351053 <second: move Re2
Interrupting first
1351053 >first : time 21093
1351053 >first : otim 25005
1351053 >first : e7e2
1351073 <second:
1351113 <first : -1 -2 3548 6956956 h6h5
1351133 <first : 0 -37 3548 6956957 h6h5
1351133 <first : -1 71 0 1 f3d4
1351133 <first : 0 37 0 2 f3d4
1351133 <first : 1 44 0 3 b3c4
1351133 <first : 2 41 0 1173 d2f4
1351133 <first : 3 41 1 3063 d2f4
1351133 <first : 4 39 3 10464 d2f4
1351303 <first : 5 39 22 79834 d2f4
1351424 <first : 6 39 35 130883 d2f4
1351774 <first : 7 39 69 265695 d2f4
1352595 <first : 8 39 152 607164 d2f4
1354148 <first : 9 39 307 1244604 d2f4
1360767 <first : 10 39 968 3999580 d2f4
GameEnds(32, Black wins on time, 4)
Interrupting first
1561996 >first : result 0-1 {Black wins on time}
Interrupting second
1561996 >second: result 0-1 {Black wins on time}
1562097 >first : quit
1562697 >second: quit
Exiting: Match "MicroMax_48w.exe vs. Simontacchi v1.81-Decepticon: final score 0-1-0
GameEnds(0, (null), 2)
[Event "RWBC PSWBTM Swiss RT39"]
[Site "ESPRESSO"]
[Date "2008.01.10"]
[Round "1.4"]
[White "MicroMax_48w"]
[Black "Simontacchi_181"]
[Result "0-1"]
[TimeControl "40/900"]
[Annotator "11. +0.13 11... +0.30"]
[Number "7"]
1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8.
c3 O-O 9. h3 Na5 10. Bc2 c5 11. d3 {+0.13/10} h6 {+0.30/10} 12.
Be3 {+0.06/11} Qc7 {+0.27/10} 13. Nbd2 {-0.06/10} Be6 {+0.25/10} 14.
Nb3 {-0.11/9} Nc6 {+0.37/10} 15. Qe2 {+0.01/8} Qb6 {+0.40/9} 16.
Bd2 {-0.01/9} a5 {+0.48/10} 17. Qd1 {-0.01/9} a4 {+0.54/9} 18.
Nc1 {-0.05/10} Rfd8 {+0.52/9} 19. Ne2 {+0.10/9} d5 {+0.51/9} 20.
Ng3 {-0.01/10} d4 {+0.53/9} 21. Nf5 {+0.09/9} Bxf5 {+0.62/9} 22.
exf5 {+0.19/11} Bd6 {+0.60/9} 23. a3 {+0.30/10} Rd7 {+0.57/8} 24.
cxd4 {+0.38/10} exd4 {+0.60/9} 25. Qe2 {+0.31/9} Re7 {+0.62/9} 26.
Qd1 {+0.01/12} Rae8 {+0.64/9} 27. Rf1 {+0.29/10} Re2 {+0.68/10} 28.
b3 {+0.32/10} axb3 {+0.70/9} 29. Bxb3 {+0.36/10} R2e7 {+0.68/9} 30.
Rb1 {+0.37/10} Qa7 {+0.66/9} 31. a4 {+0.39/10} b4 {+0.65/9} 32.
Bc4 {+0.36/10} Qb7 {+0.64/9} 33. Qc1 {+0.29/9} Rd8 {+0.64/8} 34.
Bb3 {+0.24/9} Re2 {+0.67/8}
{Black wins on time} 0-1
