H6 VS SF17.09.2017

[Scacchista1977]

What usefull information did you get from that test then ?

despite the provocative tone of your question, I can assert that I, based on the 300 game tests that I did on my PC with 8 core for engine, 512 Mh hash and no book, on time 3+0 and 5 +0, SF dev was higher respectively about 22 and 24 elo better than H6.
in the test I'm leading with an increment of 1 '', this is the partial result, but of course it is still too early to give it a value to discuss ...:

[Rebel]

Yeap, without time increment these test doesn't mean anything.

This I do not understand. Shouldn't an engine's time control algorithms adjust appropriately for any increment, including "sudden death". After all, sudden death is often used to decide tied matches.

Agreed, 5m/all is probably the most used time control in the world.

[mjlef]

Yeap, without time increment these test doesn't mean anything.

This I do not understand. Shouldn't an engine's time control algorithms adjust appropriately for any increment, including "sudden death". After all, sudden death is often used to decide tied matches.

Everything depends on the overhead or lag in the communication with the GUI or application that plays the match.
If the GUI overhead is, say, 25 msec and the engine doesn't know that, it will overstep the time.
This implies that if you really want to play sudden death games, it's essential to feed the engine the correct value for the Move Overhead - if the engine publishes such a parameter.

There is also the issue of the quality of the game you produce. Starting with 5 minutes, engines will easily use 5 to 10 seconds in the early moves. And then in the final stage of the game you force them to play with a handful of milliseconds... doesn't make sense.

An easy solution to both issues is to use a small increment, it avoids the Move Overhead race, and provides some quality in the final stages of the game.

Chess engine users should not have to be concerned with such things. The GUI overhead should be pretty constant. The engine knows how long it took to make a move. It also knows how much time the GUI says it has after the next opponent move. So the engine should be able to adjust its move overhead to pretty closely match any GUI lag. Now for internet play, the lag can vary a lot, and so some human adjustment might be needed. Although the same automatic adjustment scheme should work there most of the time too, barring some random huge lag every so often.

[Milos]

Agreed, 5m/all is probably the most used time control in the world.

True for humans, absolutely false for engines.
Since this is computer chess forum, I really don't see the relevance of what humans do in their matches.
Playing with zero increment is just plain useless. But ppl certainly like to spend their electricity in useless ways so why even bother.

[Milos]

Yeap, without time increment these test doesn't mean anything.

This I do not understand. Shouldn't an engine's time control algorithms adjust appropriately for any increment, including "sudden death". After all, sudden death is often used to decide tied matches.

Sudden death is idiotic full stop. With changing just 20 lines of code (to reject all draws, increase pawn value and make average game duration parameter to 150+ moves in time management) I can make current SF have +300 Elo at sudden death TC against newest Komodo. But in all other TCs if would be 200 and more Elo weaker. So what would be the point?

[Scacchista1977]

5960x - 8 cores for engine
Hash: 512 Mb
time: 5'+0"
no book
Tbase: yes

If you care about the quality of the games, an increment is mandatory. Instead of playing 5+0 games, why not 5+1 sec or 4+1sec?

Yeap, without time increment these test doesn't mean anything.

Playing with zero increment is just plain useless. But ppl certainly like to spend their electricity in useless ways so why even bother.

I7 5960x -8 core
Ram: 32G -2400MHz
Gui: Fritz 15
Hash: 512MB
Book: no
TB: Syzygy 6 men
Time: 4'+1"



PGN
http://www20.zippyshare.com/v/Qb3WzOh1/file.html

[mjlef]

Yeap, without time increment these test doesn't mean anything.

This I do not understand. Shouldn't an engine's time control algorithms adjust appropriately for any increment, including "sudden death". After all, sudden death is often used to decide tied matches.

Sudden death is idiotic full stop. With changing just 20 lines of code (to reject all draws, increase pawn value and make average game duration parameter to 150+ moves in time management) I can make current SF have +300 Elo at sudden death TC against newest Komodo. But in all other TCs if would be 200 and more Elo weaker. So what would be the point?

How is sudden death idiotic? As I stated it is often used to decide tied matches. If you indeed make Stockfish 300 elo stronger at sudden death, I would love to see it. How about giving it a try? It is trivial to determine if sudden death is being played since it would get not movestogo UCI command and the increment would always be 0. However, I am skeptical that the changes you propose would give that kind of an elo boost. I would love to be proven wrong, so go for it.

[Milos]

How is sudden death idiotic? As I stated it is often used to decide tied matches. If you indeed make Stockfish 300 elo stronger at sudden death, I would love to see it. How about giving it a try? It is trivial to determine if sudden death is being played since it would get not movestogo UCI command and the increment would always be 0. However, I am skeptical that the changes you propose would give that kind of an elo boost. I would love to be proven wrong, so go for it.

Tied matches where? I never heard of computer chess tournament that has sudden death TC for tied matches.
If I catch some more free time in the next few weeks I will actually try it (I did something similar really long time ago and I think it's worth a try). Would be a bit funny to have 2 different evals and some modifications in search in addition to TM for 2 different TCs, but why the hell not.

[Uri Blass]

Yeap, without time increment these test doesn't mean anything.

This I do not understand. Shouldn't an engine's time control algorithms adjust appropriately for any increment, including "sudden death". After all, sudden death is often used to decide tied matches.

Sudden death is idiotic full stop. With changing just 20 lines of code (to reject all draws, increase pawn value and make average game duration parameter to 150+ moves in time management) I can make current SF have +300 Elo at sudden death TC against newest Komodo. But in all other TCs if would be 200 and more Elo weaker. So what would be the point?

How is sudden death idiotic? As I stated it is often used to decide tied matches. If you indeed make Stockfish 300 elo stronger at sudden death, I would love to see it. How about giving it a try? It is trivial to determine if sudden death is being played since it would get not movestogo UCI command and the increment would always be 0. However, I am skeptical that the changes you propose would give that kind of an elo boost. I would love to be proven wrong, so go for it.

I do not know if 300 elo is possible (at 5+0 time control) but I feel sure that at least 100 elo is possible.

An idea how to get a big improvement in sudden death is simple.

1)play slightly faster(always look at the opponent time to verify that you have a small advantage on the clock).

2)change the evaluation to prefer games as long as possible so your opponent lose on time in most games.

For that purpose you may
1)Increase the evaluation by a constant to reject a draw by repetition(small constant is enough because otherwise the opponent will not go for a draw by repetition)

2)Give a very small bonus in the evaluation for lines when no side move a pawn or capture a piece so the program will play many moves before making a pawn move in drawn positions.

[Scacchista1977]

no comments about the games posted? Are realistic data, there is something abnormal, other ....?!
I would like to know your opinion.
Ciao