Seer 2.0.0

[Archimedes]

Seer's speed on ARM will likely be pretty disappointing until I add a NEON path though.

As there is a built in support for sse instructions, on can use the sse2neon header file in the meanwhile (or may be permanently). It works for Koivisto, Sting and Winter and now for Seer (which is a lot faster now).

Seer 2.2.0 for Android:
https://app.box.com/s/a3o0qfhe7prd9lulaaesai0tq55sqydo

[connor_mcmonigle]

Seer's speed on ARM will likely be pretty disappointing until I add a NEON path though.

As there is a built in support for sse instructions, on can use the sse2neon header file in the meanwhile (or may be permanently). It works for Koivisto, Sting and Winter and now for Seer (which is a lot faster now).

Seer 2.2.0 for Android:
https://app.box.com/s/a3o0qfhe7prd9lulaaesai0tq55sqydo

Thanks, great work! Your compile relying on the sse2neon header seems to outperform the compiles I created previously on my phone (using Termux) relying on the generic fall back and auto vectorization by a fair bit. It would seem compilers struggle to efficiently auto vectorize dot products pretty universally as of yet.

[connor_mcmonigle]

I've released a new version (v2.3.0) of Seer here: https://github.com/connormcmonigle/seer ... tag/v2.3.0

It should be significantly stronger than the previous release (v2.2.0) and tested at >= 100 elo in self play. As with all previous versions >= v2.0.0 Seer is trained on unique data generated solely from Seer's search+EGTB and does not rely on training code/inference code etc. derived from other engines. Training code and data generation code can be found at https://github.com/connormcmonigle/seer ... e/selfplay.

I've attempted to simplify my naming conventions for binaries. As with the previous release, the SSE3+nopopcnt binary is marked as unofficial and I would prefer if testers refrained from using it for official rating lists/tournaments.

[CMCanavessi]

I've released a new version (v2.3.0) of Seer here: https://github.com/connormcmonigle/seer ... tag/v2.3.0

It should be significantly stronger than the previous release (v2.2.0) and tested at >= 100 elo in self play. As with all previous versions >= v2.0.0 Seer is trained on unique data generated solely from Seer's search+EGTB and does not rely on training code/inference code etc. derived from other engines. Training code and data generation code can be found at https://github.com/connormcmonigle/seer ... e/selfplay.

I've attempted to simplify my naming conventions for binaries. As with the previous release, the SSE3+nopopcnt binary is marked as unofficial and I would prefer if testers refrained from using it for official rating lists/tournaments.

Awesome release, Connor! Do you have plans to implement ponder and/or FRC?

[connor_mcmonigle]

I've released a new version (v2.3.0) of Seer here: https://github.com/connormcmonigle/seer ... tag/v2.3.0

It should be significantly stronger than the previous release (v2.2.0) and tested at >= 100 elo in self play. As with all previous versions >= v2.0.0 Seer is trained on unique data generated solely from Seer's search+EGTB and does not rely on training code/inference code etc. derived from other engines. Training code and data generation code can be found at https://github.com/connormcmonigle/seer ... e/selfplay.

I've attempted to simplify my naming conventions for binaries. As with the previous release, the SSE3+nopopcnt binary is marked as unofficial and I would prefer if testers refrained from using it for official rating lists/tournaments.

Awesome release, Connor! Do you have plans to implement ponder and/or FRC?

Haha. I think you're the answer to the question of why so many engines have FRC support I plan to add support for FRC sometime soon, though I'll likely have to train an FRC specific network for Seer to be competitive. On the other hand, I don't see ponder in Seer's future as I don't think it's a feature people really care about. However, I might add ponder support just for you In any case, you can rest assured that you'll be the first person to know when I add FRC support.

[Dokterchen]

I've released a new version (v2.3.0) of Seer here: https://github.com/connormcmonigle/seer ... tag/v2.3.0

It should be significantly stronger than the previous release (v2.2.0) and tested at >= 100 elo in self play. As with all previous versions >= v2.0.0 Seer is trained on unique data generated solely from Seer's search+EGTB and does not rely on training code/inference code etc. derived from other engines. Training code and data generation code can be found at https://github.com/connormcmonigle/seer ... e/selfplay.

I've attempted to simplify my naming conventions for binaries. As with the previous release, the SSE3+nopopcnt binary is marked as unofficial and I would prefer if testers refrained from using it for official rating lists/tournaments.

Congratulations! Incredible progress!

[matejst]

Had a quick look at Seer 2.3.0, comparing his eval in analysis with other engines I use (Komodo 8/12, Berserk 4.5.1, Slow 2.6 and I even tried an SF derivative for a minute). Although slower, his evaluation is excellent. I used some closed positions of the French and Ruy Lopez -- usually, in the Ruy Lopez there are no problems, but in the Petrosian var. of the French, engines tend to overestimate white advantage and to wander a bit. Seer probably too, but I thought much less. In some difficult positions I had analysed extensively, it found the "best" move (if it is the best) at very low depths. His first net a few months ago was sometimes a bit disconcerting, but already the previous version of Seer (2.2.0) I thought it was very mature, enough to use it daily. It seems that Connor's approach was really effective.

I initially thought that the differences among engines will be much lesser with the advent of NNs, but it seems it is not yet the case.

Anyway, for analysing games/repertoire, at my level especially, there is absolutely no need for the "top[est] of the shelve" (Seer is already at the "top"), and I even doubt it makes objectively a difference. I guess it is easier for a human to "understand" (if it is only possible) the positional assessment when the engine is slower. One has to try the variations anyway, and it takes more time for the human than the engine, so speed, over a certain point, becomes irrelevant. I should add a disclaimer: I personally prefer to use engines with original concepts -- it is not only a way to support the authors (although money would be preferable...) who, so often, have only the pleasure to know that their creation is used -- but from the short history of computer chess, being different allowed big jumps in general progress.

I have to add that I did not have the time to test it in tactical positions in this short lapse of time, but in combination with SlowChess, Berserk, I guess there will be no mistake.

Finally, I would be very grateful if the author added some usability options, like multi-pv, if it is possible.

[connor_mcmonigle]

...
Congratulations! Incredible progress!

Thanks!

Had a quick look at Seer 2.3.0, comparing his eval in analysis with other engines I use (Komodo 8/12, Berserk 4.5.1, Slow 2.6 and I even tried an SF derivative for a minute). Although slower, his evaluation is excellent. I used some closed positions of the French and Ruy Lopez -- usually, in the Ruy Lopez there are no problems, but in the Petrosian var. of the French, engines tend to overestimate white advantage and to wander a bit. Seer probably too, but I thought much less. In some difficult positions I had analysed extensively, it found the "best" move (if it is the best) at very low depths. His first net a few months ago was sometimes a bit disconcerting, but already the previous version of Seer (2.2.0) I thought it was very mature, enough to use it daily. It seems that Connor's approach was really effective.

I initially thought that the differences among engines will be much lesser with the advent of NNs, but it seems it is not yet the case.

Anyway, for analysing games/repertoire, at my level especially, there is absolutely no need for the "top[est] of the shelve" (Seer is already at the "top"), and I even doubt it makes objectively a difference. I guess it is easier for a human to "understand" (if it is only possible) the positional assessment when the engine is slower. One has to try the variations anyway, and it takes more time for the human than the engine, so speed, over a certain point, becomes irrelevant. I should add a disclaimer: I personally prefer to use engines with original concepts -- it is not only a way to support the authors (although money would be preferable...) who, so often, have only the pleasure to know that their creation is used -- but from the short history of computer chess, being different allowed big jumps in general progress.

I have to add that I did not have the time to test it in tactical positions in this short lapse of time, but in combination with SlowChess, Berserk, I guess there will be no mistake.

Finally, I would be very grateful if the author added some usability options, like multi-pv, if it is possible.

Thanks for the kind words. I always find it interesting to see how Seer evaluates (or misevaluates!) positions as Seer is, to the best of my knowledge, one of only a handful of engines with an evaluation function not trained directly or indirectly from any other engine. Most other engines, at some point in their respective histories, trained/tuned their evaluation functions on data originating from Stockfish or some other top engine (such as Zurichess data (Stockfish) or Ethereal data (which itself was initially tuned on Zurichess data)). With a classical evaluation function and many self play iterations, that initial influence is probably mostly irrelevant anyways, but I still think it's cool. Others outside of Seer with this property are SlowChess, Leela and some of Daniel Shawul's networks (though I think the official Scorpio CNN was trained on Lc0 data? I'm not sure).

As for usability enhancements, I plan to add proper mate score reporting, syzygy probing code and maybe multipv support (I'm still a little undecided here as it would require some extra complexity. I might try a different approach where one thread is used per line as multipv is only used for analysis anyways).

[matejst]

As for usability enhancements, I plan to add proper mate score reporting, syzygy probing code and maybe multipv support (I'm still a little undecided here as it would require some extra complexity. I might try a different approach where one thread is used per line as multipv is only used for analysis anyways).

Connor, I closely follow the way you develop your engine, and I feel that your tremendous idea for the net could be even more fruitful -- the progress between new iterations of the net is a clear witness of that. About usability: it works for me the way it is now -- I often use two engines at the same time to get different assessments -- so, just enjoy yourself, and continue with the good work.

[Rebel]

Seer 2.3.0 +54 elo 3305

https://prodeo.actieforum.com/t358p25-g ... sults#4077

Only a few elo away from the top-10