82nd Amateur Series Division 8

[No4b]

Congratulations to Alexander (Drofa author) for winning this division and gaining promotion for the next series.

The tournament was one of my most popular.
The broadcast was well supported. Thanks.

I watched most of the Drofa and Supenova games from the pgn, really entartaining!
Thanks for the tournament!

You see ? My horse won

Somebody was betting on Drofa, its nice and unexpected

[Ras]

Somebody was betting on Drofa, its nice and unexpected

Btw., I have Drofa 1.3.7 in my regular engine tests as opponent and noticed that it has some issues:

1) Illegal PVs. In the last move of a PV, there is sometimes an illegal move because the in-check detection seems to happen only one level further down.
2) Rules infractions. I didn't investigate further.

Both tested using c-chess-cli under Linux. One special thing about that program is that it doesn't send the whole game notation, only FEN since the last reversible move and then the move list since that. Maybe Drofa's FEN parser has some problems.

[No4b]

Somebody was betting on Drofa, its nice and unexpected

Btw., I have Drofa 1.3.7 in my regular engine tests as opponent and noticed that it has some issues:

1) Illegal PVs. In the last move of a PV, there is sometimes an illegal move because the in-check detection seems to happen only one level further down.
2) Rules infractions. I didn't investigate further.

Both tested using c-chess-cli under Linux. One special thing about that program is that it doesn't send the whole game notation, only FEN since the last reversible move and then the move list since that. Maybe Drofa's FEN parser has some problems.

I fixed illegal PV in the 2.0.1, one of the bugs that were legacy of ShallowBlue and i was too lazy to fix it tilll now.
What does "rules infractions" means exactly? I routinely run ~5000-20000 games tournaments with no crushes (both Lunix and Windows, cutechess-cli). Never tried c-chess-cli thought. Does your second point means drofa printing illegal moves in the middle of the PV?

Than both got fixed in the 2.0.1 (at least i think so....). The issue was during the search in the ShallowBlue if alpha was not improved random move was put into TT. As i moved to the pseudo-legal move generation in Drofa, that would mean ilegal moves could go into the TT, rarely causing corrupt PVs (easiest +15 elo )


I dont really understand what you mean by FEN notation etc, isnt engines supposed to output smth like this during play:

Code: Select all

11557 >Drofa_dev(0): position startpos moves g1f3 g8f6 c2c4 e7e6 b1c3 f8b4 d1c2 e8g8 a2a3 b4c3 c2c3 d7d6 b2b4 a7a5 c1b2 e6e5 d2d3 c8g4 b4b5 a5a4 f3d2 c7c6 d3d4 c6b5 c4b5 b8d7 e2e4 f8e8 f2f3 g4h5 a1c1 d6d5 g2g4 d5e4 f3e4 e5d4 c3d4 h5g4 e1f2 g4h5
11557 >Drofa_dev(0): isready
11557 <Drofa_dev(0): readyok
11557 >Drofa_dev(0): go wtime 3750 btime 7386 winc 100 binc 100
11558 <Drofa_dev(0): info depth 1 seldepth 1 nodes 102 score cp -49 nps 102000 time 1 pv f1d3 
11558 <Drofa_dev(0): info depth 2 seldepth 3 nodes 1454 score cp -71 nps 1454000 time 1 pv f1d3 d7e5 
11562 <Drofa_dev(0): info depth 3 seldepth 5 nodes 9482 score cp -65 nps 1896000 time 5 pv f1g2 d8a5 d4d3 
11567 <Drofa_dev(0): info depth 4 seldepth 8 nodes 21728 score cp -65 nps 2172000 time 10 pv h1g1 d8a5 f1h3 d7e5 
11568 <Drofa_dev(0): info depth 5 seldepth 9 nodes 24646 score cp -64 nps 2240000 time 11 pv h1g1 d8a5 f1h3 d7e5 d4d6 
11598 <Drofa_dev(0): info depth 6 seldepth 11 nodes 87644 score cp -101 nps 2137000 time 41 pv h1g1 d8a5 b2c3 a5c7 g1g3 h5g4 
11614 <Drofa_dev(0): info depth 7 seldepth 12 nodes 119524 score cp -103 nps 2096000 time 57 pv h1g1 d7e5 h2h3 d8d4 b2d4 a8d8 f2e3 
11629 <Drofa_dev(0): info depth 8 seldepth 12 nodes 149694 score cp -81 nps 2079000 time 72 pv h1g1 d7e5 h2h3 d8d4 b2d4 a8d8 f2e3 h7h6 
11657 <Drofa_dev(0): info depth 9 seldepth 13 nodes 204199 score cp -96 nps 2041000 time 100 pv h1g1 d7e5 h2h3 e8e6 f2e3 h5g6 f1e2 e6d6 d4e5 
12093 <Drofa_dev(0): info depth 10 seldepth 15 nodes 1157076 score cp -127 nps 2158000 time 536 pv h2h3 h5g6 f1g2 d8b8 g2f3 h7h6 h1e1 b8h2 f3g2 h2f4 
12093 <Drofa_dev(0): bestmove h2h3

A few engines i tested just now all output stuff like this. At the same time i can assume what is happening with not printing whole game, it should be some of my laziness in the repetition detection code showing. Maybe later i`ll install c-chess-cli and investigate its inputs and outputs for more detail.

[Ras]

What does "rules infractions" means exactly?

Actually illegal "bestmove", thus losing the game.

I dont really understand what you mean by FEN notation

The UCI driving GUI or CLI can either use "position startpos moves ..." followed by all the moves in the game, or it can use "position fen ... moves ..." since the last irreversible move in the game. The latter idiom relies on the FEN parser in the engine even for continuous games, not just for analysing positions.

[No4b]

What does "rules infractions" means exactly?

Actually illegal "bestmove", thus losing the game.

I dont really understand what you mean by FEN notation

The UCI driving GUI or CLI can either use "position startpos moves ..." followed by all the moves in the game, or it can use "position fen ... moves ..." since the last irreversible move in the game. The latter idiom relies on the FEN parser in the engine even for continuous games, not just for analysing positions.

It is really strange. I just checked my file with ~40000 Drofa_dev testgames and it has no single loss by illegal move.
I also have done a bit of tournaments with epd book (ie FENs book), it was all seemed to be alright.
I guess i have to test under c-chess-cli to test how Drofa reacts to more broad pgn inputs.

[Ras]

It is really strange. I just checked my file with ~40000 Drofa_dev testgames and it has no single loss by illegal move.

I activated logging, and the problem isn't actually illegal moves, but no "bestmove" at all. The error message was a bit ambigous.

This happens because the time grows short towards the end of the game. I'm testing at 10s per game without increments, and it seems that Drofa is not designed for that kind of time control. It uses much time early on, and towards the end, there isn't enough time to compute any move.

Here's how the time usage looks over a game that ended with Drofa not putting out a "bestmove":

Code: Select all

Drofa: White
CT800: Black
10s per game

wtime 10000 winc 0 btime 10000 binc 0
wtime 9387 winc 0 btime 9844 binc 0
wtime 8883 winc 0 btime 9757 binc 0
wtime 8302 winc 0 btime 9603 binc 0
wtime 7813 winc 0 btime 9602 binc 0
wtime 7096 winc 0 btime 9494 binc 0
wtime 6633 winc 0 btime 9407 binc 0
wtime 5927 winc 0 btime 9299 binc 0
wtime 4982 winc 0 btime 9140 binc 0
wtime 4557 winc 0 btime 8998 binc 0
wtime 4237 winc 0 btime 8851 binc 0
wtime 3909 winc 0 btime 8734 binc 0
wtime 3612 winc 0 btime 8625 binc 0
wtime 3401 winc 0 btime 8505 binc 0
wtime 3136 winc 0 btime 8312 binc 0
wtime 2842 winc 0 btime 8119 binc 0
wtime 2588 winc 0 btime 7993 binc 0
wtime 2433 winc 0 btime 7828 binc 0
wtime 2232 winc 0 btime 7710 binc 0
wtime 2050 winc 0 btime 7567 binc 0
wtime 1910 winc 0 btime 7445 binc 0
wtime 1695 winc 0 btime 7344 binc 0
wtime 1598 winc 0 btime 7195 binc 0
wtime 1480 winc 0 btime 7024 binc 0
wtime 1363 winc 0 btime 6863 binc 0
wtime 1239 winc 0 btime 6717 binc 0
wtime 1158 winc 0 btime 6577 binc 0
wtime 1067 winc 0 btime 6436 binc 0
wtime 1001 winc 0 btime 6279 binc 0
wtime 914 winc 0 btime 6159 binc 0
wtime 830 winc 0 btime 6158 binc 0
wtime 772 winc 0 btime 6069 binc 0
wtime 666 winc 0 btime 5993 binc 0
wtime 596 winc 0 btime 5908 binc 0
wtime 548 winc 0 btime 5807 binc 0
wtime 494 winc 0 btime 5730 binc 0
wtime 451 winc 0 btime 5696 binc 0
wtime 414 winc 0 btime 5673 binc 0
wtime 342 winc 0 btime 5646 binc 0
wtime 324 winc 0 btime 5612 binc 0
wtime 295 winc 0 btime 5573 binc 0
wtime 242 winc 0 btime 5459 binc 0
wtime 214 winc 0 btime 5344 binc 0
wtime 176 winc 0 btime 5247 binc 0
wtime 146 winc 0 btime 5174 binc 0
wtime 129 winc 0 btime 5102 binc 0
wtime 91 winc 0 btime 4982 binc 0
wtime 68 winc 0 btime 4877 binc 0
wtime 48 winc 0 btime 4796 binc 0
wtime 29 winc 0 btime 4705 binc 0
wtime 16 winc 0 btime 4612 binc 0
wtime 6 winc 0 btime 4582 binc 0

[No4b]

It is really strange. I just checked my file with ~40000 Drofa_dev testgames and it has no single loss by illegal move.

I activated logging, and the problem isn't actually illegal moves, but no "bestmove" at all. The error message was a bit ambigous.

This happens because the time grows short towards the end of the game. I'm testing at 10s per game without increments, and it seems that Drofa is not designed for that kind of time control. It uses much time early on, and towards the end, there isn't enough time to compute any move.

Here's how the time usage looks over a game that ended with Drofa not putting out a "bestmove":

Code: Select all

Drofa: White
CT800: Black
10s per game

wtime 10000 winc 0 btime 10000 binc 0
wtime 9387 winc 0 btime 9844 binc 0
wtime 8883 winc 0 btime 9757 binc 0
wtime 8302 winc 0 btime 9603 binc 0
wtime 7813 winc 0 btime 9602 binc 0
wtime 7096 winc 0 btime 9494 binc 0
wtime 6633 winc 0 btime 9407 binc 0
wtime 5927 winc 0 btime 9299 binc 0
wtime 4982 winc 0 btime 9140 binc 0
wtime 4557 winc 0 btime 8998 binc 0
wtime 4237 winc 0 btime 8851 binc 0
wtime 3909 winc 0 btime 8734 binc 0
wtime 3612 winc 0 btime 8625 binc 0
wtime 3401 winc 0 btime 8505 binc 0
wtime 3136 winc 0 btime 8312 binc 0
wtime 2842 winc 0 btime 8119 binc 0
wtime 2588 winc 0 btime 7993 binc 0
wtime 2433 winc 0 btime 7828 binc 0
wtime 2232 winc 0 btime 7710 binc 0
wtime 2050 winc 0 btime 7567 binc 0
wtime 1910 winc 0 btime 7445 binc 0
wtime 1695 winc 0 btime 7344 binc 0
wtime 1598 winc 0 btime 7195 binc 0
wtime 1480 winc 0 btime 7024 binc 0
wtime 1363 winc 0 btime 6863 binc 0
wtime 1239 winc 0 btime 6717 binc 0
wtime 1158 winc 0 btime 6577 binc 0
wtime 1067 winc 0 btime 6436 binc 0
wtime 1001 winc 0 btime 6279 binc 0
wtime 914 winc 0 btime 6159 binc 0
wtime 830 winc 0 btime 6158 binc 0
wtime 772 winc 0 btime 6069 binc 0
wtime 666 winc 0 btime 5993 binc 0
wtime 596 winc 0 btime 5908 binc 0
wtime 548 winc 0 btime 5807 binc 0
wtime 494 winc 0 btime 5730 binc 0
wtime 451 winc 0 btime 5696 binc 0
wtime 414 winc 0 btime 5673 binc 0
wtime 342 winc 0 btime 5646 binc 0
wtime 324 winc 0 btime 5612 binc 0
wtime 295 winc 0 btime 5573 binc 0
wtime 242 winc 0 btime 5459 binc 0
wtime 214 winc 0 btime 5344 binc 0
wtime 176 winc 0 btime 5247 binc 0
wtime 146 winc 0 btime 5174 binc 0
wtime 129 winc 0 btime 5102 binc 0
wtime 91 winc 0 btime 4982 binc 0
wtime 68 winc 0 btime 4877 binc 0
wtime 48 winc 0 btime 4796 binc 0
wtime 29 winc 0 btime 4705 binc 0
wtime 16 winc 0 btime 4612 binc 0
wtime 6 winc 0 btime 4582 binc 0

Oh, yes, under low TC without increment it happens somewhat often.
It is a consequence of some TC patch i introduced. It gains elo on the long TC, doing mostly equal at low TC with increment and losing elo and crushing at low TC without increment.
I just assumed no one would use something like 10sec + 0 TC. I was clearly wrong.

Thanks for bringing that up to me, i`ll write special TC rules for low TC with no increment somewhere on the road to 3.0.0