draw simple (winning) endgame ?

[tissatussa]

It's a pitty Bagatur (v2.3) does not play the endgame well without TBs .. in this position Bagatur draws with Black !?

This position is winning for Black (eg. see https://syzygy-tables.info/?fen=8/8/1k2Kp2/5P2/8/2b5/8/8_w_-_-_0_1 ) but Bagatur gives away its only pawn and this game ended in a draw. Why didn't Bagatur put the bishop on e5 and tried to capture the white pawn by forcing tempos ? I guess such positions, although they have few pieces, are hard to calculate but i can't imagine why ..

I have no TBs on my system. Did you know that online TBs exist, even the latest ones with 7 pieces? When the user has an internet connection while playing, an engine can consult these TBs, eg. see the 'OnlineSyzygy' config option of the Weiss chess engine ( https://github.com/TerjeKir/weiss/ ) which can query the online 7 piece Syzygy tablebases hosted by lichess.

[AlexBrunetti]

If I may drop a line, such positions are trivial to calculate and an engine without tablebases can win them with no special efforts.
So the problem has nothing to do with TBs,

Alex

[bagaturchess]

Hi and thanks to both of you for showing and commenting this position.
Yes, indeed, Bagatur has very little knowledge for endgames. I know that some engines have specific handling into the evaluation function for different endgame positions, which are covered by the chess books and chess theory.
In regards to endgames, Bagatur supports only:

• Manhattan distance which helps to find faster and easier mates when there are no pawns for both sides.
• Endgames with differently colored single bishops. Bagatur knows that the probability of draw is higher, even when the pawns balance is +/- 1 or even 2 pawns.

The attached position to this issue is not one of these two variants.
It should work, I don't know how deep (after how many moves) is the pawn promotion and how much time has Bagatur to think about this position?

In general, the special handling of endgame positions is not on the top of Bagatur features backlog. Most people will have internet or downloaded upfront Syzygy tables on their computers. Bagatur has incorporated a few syzygy TBs in ./data/egtb directory and they cover big amount of possible endgame positions as well as many more complex positions which at the end are decomposed to TB hits.

OnlineSyzygy option sounds interesting. I will read and research about it ...

Best regards,
Krasimir
P.S. what about here (scroll down and look at the right side) https://syzygy-tables.info/

[tissatussa]

Alex wrote "..an engine without tablebases can win [such positions] with no special efforts.." and i agree : we might expect an engine is capable of winning this position, at least not giving its last pawn !? You explain why this happens because of how Bagatur works, even using its TBs, but anyhow ..

OnlineSyzygy option sounds interesting. I will read and research about it.

This seems rather easy, you can just call the API.
Not so long ago i helped the author of Weiss with this and he implemented it very quickly .. you could find that Issue for more info.

P.S. what about here (scroll down and look at the right side) https://syzygy-tables.info/

You mean the user can download TBs here .. well, the 3-5 pieces files are upto 1 Gb, which is realistic, but the 6 and 7 pieces files are too big for me .. using some online TB API is much easier (and works very fast).

[bagaturchess]

Hi,

ok, let's keep this issue open until I succeed to implement this new feature..
I am open to check this API.
Do you know whether we need permission from the owners or license in order to use it?

Best regards,
Krasimir

[tissatussa]

Take a look at my issue of the Weiss engine, at 14 July : TerjeKir/weiss#497 .. i guess you can just contact the creator how to implement the LiChess API. He seems willing to help.

[tissatussa]

i have no idea how to program a chess engine .. i'm only beginning to understand the basics while using / testing several open source chess engines and communicate with their creators .. however, i have a fairly good understanding of the chess game, i'm a club player myself with rating about 1850 .. so, the fact that Bagatur is unable to win this endgame surprised me .. i have no clue how you can solve this, i guess the problem is at the core ..

maybe this info can help you : i just stumbled upon this text of the Seer engine at https://github.com/connormcmonigle/seer-nnue :

Seer is an original, strong UCI chess engine. Seer relies on a neural network estimating WDL probabilities for position evaluation. Seer's network is trained through a novel retrograde learning approach starting only from 6-man syzygy EGTB WDL values. These initial WDL scores are then iteratively backed up to 32-man chess positions using Seer's search to find continuations from N-man chess positions to N-1-man chess positions (implementation). Seer uses a conventional alpha-beta search combined with "Lazy SMP" (shared transposition table) for multithreading support.

i know Bagatur does not rely on any NN, but maybe the approach of Seer (which is unique, i think) will inspire you ..

[bagaturchess]

Sounds very interesting!
I have experience with NNs and tried them with Bagatur in the past anyway, for the evaluation function. To solve endgames issue with NNs is very good application!

FYI: https://tablebase.lichess.ovh/tables/standard/
A contains Syzygi and Gaviota TBs downloads:
3-4-5/ 24-Jun-2021 12:59 -
6-dtz/ 11-Apr-2018 19:47 -
6-wdl/ 11-Apr-2018 19:47 -
7/ 05-Sep-2018 21:58 -
Best regards,
Krasimir

[bagaturchess]

Hi,
I have tried to call lichess API with, for example, this url http://tablebase.lichess.ovh/standard?fen=3k4/8/8/8/8/8/3P4/3K4_w_-_-_0_1
It takes 135 milliseconds to get back the response from the server.
This means that the feature will work only if there is at least 150 milliseconds per move. I will set the minimum time per move to even 500 milliseconds to be on the save side. This feature will work only if there is more than 500 milliseconds per move.
Is this ok from your perspective?
Best regards,
Krasimir

[tissatussa]

The author of Weiss had the same "problem" : i remember he wrote that the LiChess API does not accept too many requests (per time) which is logical and realistic -- i guess you should be able find this on his GitHub pages .. consulting such online service will always have some limit, isn't it ?

[tissatussa]

Here is the remark of the Weiss author :
I noticed if weiss plays vs itself with both using it, it queries too often and lichess refuses to respond sometimes, but should be fine as long as opponent isn't moving instantly as well.

[bagaturchess]

Hi,

the server is giving very often "Server returned HTTP response code: 429 Too Many Requests".
Code 429 means "The user has sent too many requests in a given amount of time ("rate limiting")"

At the end my measurements shows that only 1 request per 60 seconds is allowed.

What time control are you using to run games?

Best regards,
Krasimir

[tissatussa]

1 request per 60 sec ? This can not be right .. maybe you can look into the Weiss code, to see how this author did it .. or just contact him when you don't succeed .. honestly, don't hesitate to do that .. i usually do about 8 minutes per player per game, with bonus 5 sec per move.

[AlexBrunetti]

This means that the feature will work only if there is at least 150 milliseconds per move. I will set the minimum time per move to even 500 milliseconds to be on the save side. This feature will work only if there is more than 500 milliseconds per move.

Do you probe TB just one time per search?

[bagaturchess]

Hi, yes, exactly.
The online request to the server is send once per search, in the begging, even before starting the search.
My test games were with 1 minute per game +1 second per move.
This doesn't work with such time control.
It should be minimum 60 seconds per move in order to use this feature.
Best regards,
Krasimir

[bagaturchess]

Hi,

I have an update here.

Now the implementation is with adaptive waiting time between the server requests.
It varies between the minimum of 500 ms (0.5 secs) and the maximum of 64000 ms (64 secs).
Current waiting time is dynamically divided by 2 if server replies with good answers and is multiplied by 2 if the server returns error.

I believe this is the best approach. What do you think?

This big waiting times could be on my setup only, because I have created a lot of requests last 24h and my IP/MAC Address might be restricted from the server.

On my laptop it works like this:
Try 1: OK
Waiting 500 ms
Try 2: FAILED
Waiting 1000 ms
Try 3: FAILED
Waiting 2000 ms
Try 4: FAILED
Waiting 4000 ms
Try 5: FAILED
Waiting 8000 ms
Try 6: FAILED
Waiting 16000 ms
Try 7: OK
Waiting 8000 ms
Try 8: FAILED
Waiting 16000 ms
Try 9: FAILED
Waiting 32000 ms
Try 10: OK
Waiting 16000 ms
Try 11: FAILED
Waiting 32000 ms
Try 12: FAILED
Waiting 64000 ms
Try 13: FAILED
Waiting 64000 ms
Try 14: OK
Waiting 32000 ms
Try 15: OK
Waiting 16000 ms
Try 16: FAILED
Waiting 32000 ms
Try 17: OK
Waiting 16000 ms
Try 18: FAILED
Waiting 32000 ms
Try 19: FAILED
Waiting 64000 ms
Try 20: FAILED
Waiting 64000 ms
Try 21: OK
Waiting 32000 ms
Try 22: FAILED
Waiting 64000 ms
Try 23: OK
Waiting 32000 ms
...

Best regards,
Krasimir

[tissatussa]

i have no idea .. you should discuss this with Alex .. or with Terje Kirstihagen of the Weiss engine.

[bagaturchess]

Yes, sure I will ...
The code is pushed to github: https://github.com/bagaturchess/Bagatur/blob/master/Sources/EGTB/src/bagaturchess/egtb/syzygy/OnlineSyzygy.java
I also have removed the old code and resources related with Gaviota TB support as it will be no longer needed.
The source is available in git history of course ...
Best regards,
Krasimir

[bagaturchess]

Hi and good day! :-)
I have stabilized the master branch of the Bagatur project, but had to disable the code for Offline and Online Syzygy probing in the root positions even before starting the search. This was experimental but doesn't work correctly at the moment.

I have identified one blocker.
I think it is risky to use Syzygy probing at root positions.
According to what I understand you have to make each possible move for given root position and check WDL for each move. Than you select all WIN moves (which are actually LOSS from opponent perspective) and select this one with smallest DTZ as best move.

This doesn't work.
The engine moves correct moves but when it reach promotion move it doesn't move it. I assume this resets the DTZ and needs exceptional handling.
This is not simple, you also need to care about whether the move is 3 fold-repetition, capture or even check and have special handling for those at least ...

Any hints on how it should work are welcome !?

I will contact Terje Kirstihagen to ask him about this issue as well but let's first do my homework.

Best regards,
Krasimir

P.S. Also it is very difficult to reproduce these issues without additional effort invested in special setup and code changes. Without this I have to wait a lot of time and check periodically to observe such issue. On my static tests with Syzygy and special set of positions it works.

[tissatussa]

i do not fully understand what you mean, but that's my shortcoming, not being a chess programmer .. you should continue to investigate and test like you did .. then maybe contact another creator like Terje, and explain what you did to solve the issue, giving him enough input to help you. To my knowledge Weiss is the only engine which has implemented the online (LiChess) TBs.

[tissatussa]

On the other hand i keep thinking any engine should be able to win a simple endgame like the one i posted in this issue, without TBs. But i can be wrong ..

[bagaturchess]

Yes, why the evaluation function doesn't work in this position is a different story, which I also have to look at ... :-)

[bagaturchess]

Hi,

do you have the reported game in PGN format?

In this position "k7/8/4Kp2/5P2/8/6b1/8/8 b - - 0 1" on my setup, without TBs, Bagatur plays well - Bg3e5. It finds the only best move even on depth 1:
info depth 1 seldepth 1 time 46 nodes 2 nps 43 score cp 0 lowerbound hashfull 0 pv a8b7
info depth 1 seldepth 1 time 83 nodes 4 nps 48 score cp 8 lowerbound hashfull 0 pv a8b7
info depth 1 seldepth 1 time 83 nodes 6 nps 72 score cp 24 lowerbound hashfull 0 pv a8b7
info depth 1 seldepth 1 time 83 nodes 8 nps 96 score cp 56 lowerbound hashfull 0 pv a8b7
info depth 1 seldepth 1 time 83 nodes 10 nps 120 score cp 120 lowerbound hashfull 0 pv a8b7
info depth 1 seldepth 2 time 84 nodes 19 nps 226 score cp 248 lowerbound hashfull 0 pv g3h4
info depth 1 seldepth 2 time 85 nodes 32 nps 376 score cp 338 upperbound hashfull 0
info depth 1 seldepth 2 time 85 nodes 36 nps 423 score cp 293 lowerbound hashfull 0 pv g3h4
info depth 1 seldepth 2 time 86 nodes 38 nps 441 score cp 315 lowerbound hashfull 0 pv g3h4
info depth 1 seldepth 2 time 86 nodes 43 nps 500 score cp 326 lowerbound hashfull 0 pv g3e5
info depth 2 seldepth 2 time 86 nodes 49 nps 569 score cp 387 lowerbound hashfull 0 pv g3e5 e6f7
info depth 2 seldepth 3 time 87 nodes 63 nps 724 score cp 394 upperbound hashfull 0
info depth 3 seldepth 3 time 88 nodes 90 nps 1022 score cp 371 upperbound hashfull 0
info depth 3 seldepth 4 time 89 nodes 103 nps 1157 score cp 363 lowerbound hashfull 0 pv g3e5 e6f7 a8a7
info depth 4 seldepth 4 time 89 nodes 117 nps 1314 score cp 363 lowerbound hashfull 0 pv g3e5 e6d5 a8a7
info depth 4 seldepth 6 time 95 nodes 172 nps 1810 score cp 371 lowerbound hashfull 0 pv g3e5 e6d5 a8b7 d5e6 b7c6
info depth 4 seldepth 6 time 98 nodes 215 nps 2193 score cp 386 upperbound hashfull 0
info depth 5 seldepth 6 time 105 nodes 365 nps 3476 score cp 370 upperbound hashfull 0
info depth 5 seldepth 6 time 106 nodes 407 nps 3839 score cp 362 lowerbound hashfull 0 pv g3e5 e6f7 a8b7 f7g6 b7a6
info depth 6 seldepth 6 time 108 nodes 448 nps 4148 score cp 362 lowerbound hashfull 0 pv g3e5 e6f7 a8b7 f7g7 b7a6
info depth 6 seldepth 6 time 108 nodes 481 nps 4453 score cp 370 lowerbound hashfull 0 pv g3e5 e6f7 a8b7 f7e7 b7a6
info depth 6 seldepth 7 time 110 nodes 532 nps 4836 score cp 386 lowerbound hashfull 0 pv g3e5 e6f7 a8b7 f7f8 b7a6
info depth 6 seldepth 8 time 117 nodes 716 nps 6119 score cp 417 upperbound hashfull 0
info depth 6 seldepth 8 time 120 nodes 847 nps 7058 score cp 401 lowerbound hashfull 0 pv g3e5 e6f7 a8b7 f7e6 b7c6 e6f7
info depth 7 seldepth 8 time 121 nodes 904 nps 7471 score cp 401 lowerbound hashfull 0 pv g3e5 e6f7 a8b7 f7e6 b7c6 e6f7 c6d5

But in your game it plays Ka8b7 and lose the only pawn ... for now I cannot say much about this issue, it is not reproducible on my side.

Best regards,
Krasimir

[tissatussa]

indeed, when i test this position on my system, using SCID with MPV 1 or even more, Bagatur v2.3 plays Bg3-e5 almost immediately and keeps considering this move best until high depth :

here's the zipped PGN : lozza-2.0_vs_bagatur-2.3.zip
honestly, i did not alter anything .. it really happened that way .. maybe it has something to do with playing in CuteChess, but i have no clue ..

[tissatussa]

btw. it's about move 91

[tissatussa]

Note that my initial position, after Bagatur played 85...Kxb6, it reached the winning position and so i made the diagram .. this was an 8 minute game and the times you see (Lozza 00.08 and Bagatur 01.43) are the clock times when the game ended .. so Bagatur had enough time to calculate but it spent only 1.6 seconds on move 91...Kb7 !? Maybe it used its hash (normally i set 64 Mb for all engines) and thus decided to play the move .. i don't know .. it seems this issue takes another direction, maybe concerning the working of engines in CuteChess (or another GUI, i don't use Arena) .. in the meantime you're aware of the online TBs, so that's the positive side !

[bagaturchess]

Yes, thanks a lot for your support!
Most probably this is caused by transposition hash table entries and happens in very rare cases and it is close to impossible to reproduce.
I would add even more positives to online syzygy idea - I faced the issues with the probing in the root search positions, which is important not only for online probing but also for offline probing. Now I have to solve it ...
Best regards,
Krasimir
P.S. I have invited Terje Kirstihagen here to give us hints! :-) TerjeKir/weiss#558

[TerjeKir]

If you use fathom it handles any issues with probing syzygy in root. I have no idea what exactly it does for this.

For online probing it will depend on what info the api you query gives you. I probe lichess which gives all the info you need from the current position, just parse the response and play whatever move it tells you to play.

[bagaturchess]

Hi and thanks for the prompt reply!

ok, for offline probing in the root, I will check later fathom if I can understand the code at all ...

Regarding the online probing.
I also use the same service of lichess. Actually, I was pointed out by tissatussa to OnlineSyzygy UCI option / feature of Weiss.

The issues, which I face with lichess online probing, are these 2:

• Server rejects a lot of the requests with "HTTP response code: 429 Too Many Requests", Bagatur have to wait up to 60 secs in order to make another call and receive successful response from server. What are your observations and/or measurements about this requests limits? Is it because of my IP is now (after too many requests for last days) somehow banned and limited?
• When the response from the server is correct Bagatur receives mainly JSONs with "winner": null as text inside. Is this normal and returned always when the game will become draw?

Best regards,
Krasimir

[TerjeKir]

When I implemented it I got no timeouts unless both engines played ~instantly and kept querying every turn. Spamming it a bit manually worked fine now as well.

I get a big json with info about both the position and each legal move.

[bagaturchess]

FYI: here are my first and last (for now) unsuccessful try of NNUE implementation: https://github.com/bagaturchess/Bagatur/tree/master/Sources/LearningImpl/src/bagaturchess/deeplearning/impl_nnue
Best regards,
Krasimir
P.S. It is exactly, what you were looking for - simple evaluation with material and PSQT ... https://github.com/bagaturchess/Bagatur/blob/master/Sources/LearningImpl/src/bagaturchess/deeplearning/impl_nnue/NeuralNetworkUtils_NNUE_PSQT_Material.java

[bagaturchess]

Update: I am very close to finalize the evaluation weights tuning against SF14.1. Are you interested to test a few positions with it? I could upload one more temp release of the dev version ... the delta in ELO strength is still unknow, but is in the range of -/+50 ELO.
The new version is playing white :-)

ending in draw

last screenshot ...

Next game with black - again keeping the Queen

:-)

[tissatussa]

Thanks for the updates. Regarding training a NN for the 4Npos : i willl open a new Issue. There i will copy some of our texts, so we can continue from there, otherwise this Issue is getting too many different subjects, although they all are meant to improve Bagatur strength in the endgame.

[bagaturchess]

Thanks for creating different issues for each case!

So, if we assume that this issue is for the online syzygy implementation, than the only open item is:

"I don't know the answer of the following chess question, probably clear by chess theory.
In endgame in average the opponent may make more or less mistakes that you. This relates to the ELO of each player. Can we build strategy on this? For example (but also into the context of online syzygy), you can target draw as default, but don't miss opportunity and probability of win by doing moves, which have draw as target. Than can we use online syzygy draw scores/moves and when exactly it is useful?"
(e.g. DTZ scores from lichess server)

Is your understanding the same?

Best regards,
Krasimir

[tissatussa]

..we assume that this issue is for the online syzygy implementation..

yes, the subject of this Issue is "draw simple (winning) endgame ?" and we ended with the idea to implement online syzygy.

Is your understanding the same?

In fact yes : when 7 or less pieces are on the board, we can reduce mistakes by querying the online syzygy wisely, so only when 'needed'. You propose "..can target draw as default, but don't miss opportunity and probability of win by doing moves, which have draw as target" and i think that is the right appraoch.

i'm writing scenarios to implement this.

[bagaturchess]

Happy to hear that! :-)
I still wonder, isn't it guaranteed by definition from TBs?
Here are my latest thoughts about this: if we have draw game, than we must prolong it as much as possible. To not finish in 10 moves, but in 30, for example. This can be implemented by using DTZ scores I assume. Is this correct?
It probably depends also on whether the game is with perfect or non-perfect play. With TBs we have perfect play and in all other cases we have non-perfect play ...

[tissatussa]

my current raw notes :

I imagine / deduce 3 scenarios :

Own eval tells a max-7-piece position is (probably) :

scenario 1
DRAW [ several best moves may reach this result ]

query can give:

• draw possible (Nd moves)
• winning possible (Nw moves)
• losing possible (Nl moves)
  [ save this query ]

If WINNING is yet possible, although own eval was DRAW,
then take the best winning move and trust own eval for next moves : don't query too often !
I propose : as soon as the query tells WINNING, do no longer query on next moves because own eval will likely be WINNING !?

Else if DRAW is possible, the query has confirmed own eval.
Take the best drawing move, which is probably the 'shortest' route - if any.
I propose : do no longer query on next moves, unless the eval drops to much : don't query too often !
Trust own eval for next move(s) because own eval will likely be DRAW !?

Else if only LOSING is possible, just rely on own eval, which tells DRAW !
I propose : do no longer query, only until own eval drops to "probably losing" (scenario 3).

scenario 2
WINNING [ several best moves may reach this result ]

Although own eval tells WINNING, we query the online syzygy, which can give:

• draw possible (Nd moves)
• winning possible (Nw moves)
• losing possible (Nl moves)
  [ save this query ]

(------------writing)

scenario 3
LOSING [ several best moves may reach this result ]

(------------writing)

[tissatussa]

you see, i envision some states of the program and try to deduce them .. goal is to wisely query : not too often.

[tissatussa]

if my logic of this idea is correct, you could even complete this scenario list or change it ?

[bagaturchess]

Thanks a lot for putting this together in text!
The main problem is that we don't know the own search result upfront. It is unknown when we query TB server. The server request and own search starts in parallel to each other.
We can do static evaluation of the position upfront or we can do shallow search to check for forced win of material or shallow mate. The max depth of this initial search will be no more than 3 plies.

[bagaturchess]

For now I think the only save way is:

1. check TB for winner
2. if winner is unknown, than start shallow search of 3 plies. Here we could use transposition table entries as well. If such entry exists for the position than use it. It will be more accurate than shallow search of 3 plies. TT entry is definitely better choice, especially on time controls, which are not too fast. We can use TB draws probing based on it, if presented.
3. If step 2 gives negative evaluation for the current player, for example smaller than -100 cp, than we go for TB draw scores. We also can use DTZ scores of TBs to move this draw move which will lead to faster draw as result (in less moves).

Is this correct from your perspective?

We should not consider server request limits, they are handled in a good way - waiting time between to server requests is going up and down depending on the request limits, when they are reached. So the code will make calls to the server when it can. This is a separate logic, which we already have implemented.

[tissatussa]

my idea with the scenarios is to provide a solution for querying the online-syzygy NOT TOO often. Or can you make a request EVERY move ? (as soon as max 7 pieces on the board) ? -- I guess not.

[tissatussa]

If we can query the online-syzygy every move, then in fact those TBs will play the rest of the game !? And Bagatur will move almost instantly ! Am i wrong ? I remember Weiss playing that way .. did you ever test this engine with its online TB option ?

[bagaturchess]

my idea with the scenarios is to provide a solution for querying the online-syzygy NOT TOO often. Or can you make a request EVERY move ? (as soon as max 7 pieces on the board) ? -- I guess not.

We have to decuple this 2 things: the issue with availability of online TBs and the correct way of using them. The first issue can/will be solved later, not with the first version. The second one is to use TBs in most possible ways, which are correct - they only improve engine play.

[bagaturchess]

If we can query the online-syzygy every move, then in fact those TBs will play the rest of the game !? And Bagatur will move almost instantly ! Am i wrong ? I remember Weiss playing that way .. did you ever test this engine with its online TB option ?

When we release the first version I will work more on the server limits. Than I will investigate this story, including Weiss behavior in more details. We even can create new issue for this and close this one, as it is too big now. :-) That is why I would like to release as fast as possible the Online Syzygy feature.

[tissatussa]

OK .. close this Issue. Any further communication can be done by opening a new Issue, and copy some text parts from THIS Issue for reference, like i did in the "develop NN" issue .. OK ?

[bagaturchess]

Yes, just let's finish it. :-)
I propose the following: to generalize the idea with transposition table entries available from the last / latest own search.
When server response is received, than if the TB score is better than the last available entry in the transposition table for this position, then use it. This could be done for the winning moves as well. We can do it general - use it in all scenarios.
Is this behavior correct from your perspective?

[tissatussa]

OK, that's a first question to be continued .. when you close this Issue, will YOU open a new Issue for the online syzygy implementation ? I will wait for that and respond there, OK ?

[bagaturchess]

The new issue will be for the server limits only.
I would like to use this issue until we release this feature for the first time. If you prefer to close it, that is ok for me too. :-)

[bagaturchess]

Ok, I will start working on this tomorrow:

"Generalize the idea with transposition table entries available from the last / latest own search.
When server response is received, than if the TB score is better than the last available entry in the transposition table for this position, then use it. This could be done for the winning moves as well. We can do it general - use it in all scenarios."

Now is time for relax!

Machine learning and evaluation tuning always create pressure in my head ... ;-)

[bagaturchess]

I tried this night one tournament with latest Dev version against version 2.3

Looks very good! (although 118 games are not enough to say:-) )

This is with the changes made in this issue.
Enabled offline TBs (I have changed this code) and enabled exchange motivation logic.
Online syzygy are disabled, because they are not used when we have enabled offline TBs.

One interesting draw:

[bagaturchess]

Now, I will start working on the Online Syzygy logic, from here:
https://github.com/bagaturchess/Bagatur/blob/master/Sources/EGTB/src/bagaturchess/egtb/syzygy/OnlineSyzygy.java

P.S. I hate to parse texts, but we have to go through it! ;-)
The good news are the code is already there and I have to only refactor it a bit ...

[bagaturchess]

This is the last state in this tournament:

I will stop it and run a new one, for first test of the new online syzygy code ...

[bagaturchess]

Here are the details, regarding the new code, which handles the online Syzygy feature in Bagatur:

• server logic https://github.com/bagaturchess/Bagatur/blob/master/Sources/EGTB/src/bagaturchess/egtb/syzygy/OnlineSyzygy.java
• server requests starter and transposition table logic https://github.com/bagaturchess/Bagatur/blob/master/Sources/Search/src/bagaturchess/search/impl/uci_adaptor/TimeSaver.java

Just in case, if someone is interested in this Java code ...

[bagaturchess]

Good news, regrading the server request limits!

Waiting time between requests stay at 500 ms all the time!
Also the average server response time is 185 ms (max 1200 ms).

The issue was caused by the URL of the server, which I have used up to now:
http://tablebase.lichess.ovh/standard/mainline?fen=...
It has request limits.

This one is used now:
http://tablebase.lichess.ovh/standard?fen=...
and it doesn't has request limits. :-)

Best regards,
Krasimir

[bagaturchess]

There were some bugs in the logic, which I have fixed and now next tournament is running.
This Dev version uses draw scores (not only +mate) and doesn't have lichess server request limits. The log files look very good (no errors).
The tournament is with switched on online syzygy for Dev version and with switched off offline syzygy for both Dev and 2.3 versions.
Until now, for 20 games, we have 314 server calls with 72 draw scores and 0 wins (mates) received from server and played by Bagatur. I am still waiting to verify that the mate scores are handled correctly ...

[bagaturchess]

Hi, for some reason there are still no logs from wins (mates) scores, I have to investigate why this happens.
STATISTICS [server_calls=3496, wins=0, draws=462]
It was working in the beginning, this is with what we have started ... the bug should be something simple and obvious, but I cannot found it for now ...

[bagaturchess]

Happy New Year 2022! I wish good health and good mood!
P.S. the version 3.0 is released and your feedback is welcome! ;-) I will close this issue.