Seer 2.0.0

[pohl4711]

What we see here is typical: Engines, which are getting stronger, mostly getting playing less aggressive.

That's a correct observation, nets get better because they become more balanced, thus less aggressive, I think my second reckless Rebel 14.1 net was a good example

I have been trying to make my new net more aggressive, from your tool I get:

Code: Select all

Rebel 15.1 - Number of all sacrifices         : 306 (06.12% of all games) (14.85% of won games) 
Rebel beta - Number of all sacrifices         : 375 (07.50% of all games) (17.93% of won games) 

What does it mean?

It means, you are at the right way, new Rebel sacs more often. For a programmer, the sac percents of won games is interesting.
But I strongly recommend, to use my EAS tool. It counts short wins and bad draws, too, and builds a second ratinglist with all differen percents of different sacs and short (er) games, below the first ratinglist.
Just ignore the results of the opponents of Rebel, the EAS Tool will calculate the scores for the opponents, too out of the testgames.pgn. But the tool is pretty fast, so this does not matter.
https://www.sp-cc.de/files/engines_aggr ... cs_tool.7z

Look here, scroll down to the second list, and see, what great stats you will get here...
https://www.sp-cc.de/files/statistix_eas_ratinglist.txt

[pohl4711]

I think that the way that you calculate Engine Aggressivenes Score is unfair.

Imagine an engine that has 1 win out of 100 games and the win is with a sacrifice(rest of the games are draws and losses
The engine improved and against the same opponents has 10 wins out of 100 games and 2 wins are with sacrifices(1 of them the same game that the older version won with a sacrifice.

The engine is more aggressive from my point of view because it wins more games with sacrifices but when you look at percent from won games you do not see it.

This problem can only happen, when the overall number of played games (and wins) is small. If the number of games is huge, this normalizes all stats.

If you look at the second ratinglist, you will see, that no engine in the EAS list has less than 750 wins...most of them clearly above 1000

https://www.sp-cc.de/files/statistix_eas_ratinglist.txt

Just scroll down to the second ratinglist with full stats.

[Rebel]

What we see here is typical: Engines, which are getting stronger, mostly getting playing less aggressive.

That's a correct observation, nets get better because they become more balanced, thus less aggressive, I think my second reckless Rebel 14.1 net was a good example

I have been trying to make my new net more aggressive, from your tool I get:

Code: Select all

Rebel 15.1 - Number of all sacrifices         : 306 (06.12% of all games) (14.85% of won games) 
Rebel beta - Number of all sacrifices         : 375 (07.50% of all games) (17.93% of won games) 

What does it mean?

It means, you are at the right way, new Rebel sacs more often. For a programmer, the sac percents of won games is interesting.
But I strongly recommend, to use my EAS tool. It counts short wins and bad draws, too, and builds a second ratinglist with all differen percents of different sacs and short (er) games, below the first ratinglist.
Just ignore the results of the opponents of Rebel, the EAS Tool will calculate the scores for the opponents, too out of the testgames.pgn. But the tool is pretty fast, so this does not matter.
https://www.sp-cc.de/files/engines_aggr ... cs_tool.7z

Look here, scroll down to the second list, and see, what great stats you will get here...
https://www.sp-cc.de/files/statistix_eas_ratinglist.txt

Thanks, not to pollute Connor's thread let's continue here - https://prodeo.actieforum.com/t991-for-stefan#10564

BTW Connor, great progress...

[connor_mcmonigle]

...

BTW Connor, great progress...

Thanks

[connor_mcmonigle]

I've just released Seer v2.7.0 here: https://github.com/connormcmonigle/seer ... tag/v2.7.0.

This release adds an estimated 50 Elo in self play under UHO testing conditions. This improvement in strength can be attributed to further optimizations to the network inference implementation, an improved network trained using a new regularization scheme, and a number of miscellaneous search improvements (including the addition of a semi-novel "pawn-structure-history" concept which uses the pawn hash to index into a separate history table) in roughly equal measure. As was the case for the prior release, the embedded network was trained solely on data originating from Seer produced by way of many self play iterations starting with the initial "retrograde learning" network bundled with v2.0.0-v2.1.0 as a base.

The complete patch history can be found here for those interested: https://github.com/connormcmonigle/seer ... 0...v2.7.0

[Graham Banks]

Seer not working on my 5950x.
Starts using time, but nothing displayed, and time just runs out.

[connor_mcmonigle]

Seer not working on my 5950x.
Starts using time, but nothing displayed, and time just runs out.

Could you provide some logs to assist in debugging what's going on?

[Modern Times]

Seer not working on my 5950x.
Starts using time, but nothing displayed, and time just runs out.

I ran the bulk of my 2,800 Chess324 games 2.7.0 on my Ryzen 5900X with no issues. That was under Cutechess GUI.

[connor_mcmonigle]

Graham shared some logs and I was able to identify that the problem was caused by ChessGUI errantly omitting `winc` and `binc` keys when sending the go command to the engine. Separately, I'd broken sudden death time control handling with a refactor. I've subsequently fixed sudden death time control handling and updated the 2.7.0 release binaries (I decided not to cut a 2.7.1 release as the scope of the impact was pretty minimal - does anyone even care about sudden death?). In any case, I suspect Damir's issues are also related. Thanks all!

https://github.com/connormcmonigle/seer ... tag/v2.7.0

[Graham Banks]

Graham shared some logs and I was able to identify that the problem was caused by ChessGUI errantly omitting `winc` and `binc` keys when sending the go command to the engine. Separately, I'd broken sudden death time control handling with a refactor. I've subsequently fixed sudden death time control handling and updated the 2.7.0 release binaries (I decided not to cut a 2.7.1 release as the scope of the impact was pretty minimal - does anyone even care about sudden death?). In any case, I suspect Damir's issues are also related. Thanks all!

https://github.com/connormcmonigle/seer ... tag/v2.7.0

Thanks for the fix.