Progress on Loki

[niel5946]

LNN's first game

Today, I finished the UCI-LNN implementation which means that a net can now be loaded and used by Loki
Right after I did this, I played a game against it and got completely crushed , so I thought a more reasonable opponent would be Loki 3.0. This is how the game went:
[pgn][Event "My Tournament"]
[Site "?"]
[Date "2021.06.05"]
[Round "1"]
[White "Loki LNN"]
[Black "Loki 3.0.0 64-bit"]
[Result "0-1"]
[ECO "B01"]
[GameDuration "00:01:45"]
[GameEndTime "2021-06-05T14:50:35.676 Rom, sommertid"]
[GameStartTime "2021-06-05T14:48:49.949 Rom, sommertid"]
[Opening "Scandinavian (center counter) defense"]
[PlyCount "104"]
[TimeControl "60+0.1"]

1. e4 {+0.28/7 2.1s} d5 {-0.22/9 2.1s} 2. exd5 {+0.39/7 2.0s} c6 {-0.55/10 2.0s}
3. c4 {+0.50/8 1.9s} Nf6 {-0.27/11 1.9s} 4. Nc3 {+0.58/7 1.9s}
cxd5 {-0.27/10 1.9s} 5. cxd5 {+0.46/8 1.8s} Nxd5 {-0.35/10 1.8s}
6. d4 {+0.42/7 1.8s} e6 {-0.27/9 1.7s} 7. Nf3 {+0.49/7 1.7s} Bb4 {-0.35/9 1.7s}
8. Bd2 {+0.47/7 1.6s} O-O {-0.62/9 1.6s} 9. Bc4 {+0.58/7 1.6s}
Bxc3 {-0.36/9 1.6s} 10. bxc3 {+0.37/8 1.5s} Qc7 {-0.56/9 1.5s}
11. Qe2 {+0.70/7 1.5s} Nc6 {-0.43/9 1.5s} 12. O-O-O {+0.61/6 1.5s}
a5 {+0.36/9 1.4s} 13. Rhe1 {+0.83/6 1.4s} a4 {+0.45/9 1.4s}
14. Qe4 {+0.67/6 1.4s} Ncb4 {+0.72/10 1.4s} 15. Ng5 {+0.68/7 1.3s}
Nf6 {+1.01/10 1.3s} 16. Qe2 {+0.20/8 1.3s} Nbd5 {+0.94/9 1.3s}
17. Nf3 {+0.21/7 1.2s} b5 {+1.26/10 1.2s} 18. Bxb5 {-0.09/8 1.2s}
Nxc3 {+3.45/12 1.2s} 19. Bxc3 {-1.23/8 1.2s} Qxc3+ {+4.03/12 1.2s}
20. Kb1 {-1.68/7 1.1s} Rb8 {+5.43/10 1.1s} 21. Rc1 {-3.59/7 1.1s}
Qa5 {+5.64/10 1.1s} 22. Ka1 {-3.71/6 1.1s} Rxb5 {+5.78/10 1.1s}
23. Ne5 {-4.38/6 1.0s} Bb7 {+6.33/9 1.0s} 24. g3 {-4.48/6 1.00s}
Rb4 {+6.39/8 0.99s} 25. Rc5 {-4.32/6 0.97s} Qd8 {+6.83/9 0.97s}
26. Rc4 {-4.76/6 0.94s} Ba6 {+6.72/11 0.94s} 27. Rxb4 {-3.79/8 0.91s}
Bxe2 {+7.89/11 0.91s} 28. Rxe2 {-3.96/7 0.88s} Qa8 {+8.02/10 0.88s}
29. a3 {-4.11/6 0.86s} Qh1+ {+8.53/10 0.86s} 30. Rb1 {-4.44/6 0.82s}
Qxh2 {+8.91/10 0.83s} 31. Rc1 {-4.90/6 0.80s} Qh5 {+9.01/10 0.81s}
32. Rb2 {-4.75/6 0.80s} Ne4 {+8.93/9 0.78s} 33. Re1 {-4.83/6 0.77s}
Qf5 {+9.26/9 0.76s} 34. Re3 {-5.02/6 0.74s} Rc8 {+10.02/10 0.74s}
35. Rf3 {-5.15/6 0.73s} Qh5 {+10.56/10 0.72s} 36. Ka2 {-6.23/7 0.70s}
h6 {+11.67/10 0.70s} 37. Rd3 {-5.85/7 0.68s} Nc3+ {+13.27/12 0.68s}
38. Rxc3 {-6.70/8 0.66s} Rxc3 {+13.28/11 0.66s} 39. Rb8+ {-7.20/7 0.64s}
Kh7 {+15.12/10 0.64s} 40. Kb2 {-7.45/7 0.61s} Rc7 {+16.65/11 0.62s}
41. g4 {-7.84/7 0.60s} Qh1 {+18.65/11 0.60s} 42. Nd3 {-10.42/6 0.58s}
Qd1 {+26.17/12 0.58s} 43. Ka2 {-15.18/8 0.57s} Qxd3 {+M9/8 0.57s}
44. Rb2 {-15.55/6 0.56s} Rc3 {+M7/8 0.55s} 45. Rb7 {-14.76/4 0.54s}
Rxa3+ {+M5/38 0.54s} 46. Kb2 {-M4/100 0.26s} Rb3+ {+28.04/11 0.53s}
47. Rxb3 {-17.52/7 0.52s} Qxb3+ {+28.30/9 0.51s} 48. Kc1 {-17.56/6 0.51s}
f5 {+18.72/9 0.50s} 49. gxf5 {-14.26/7 0.49s} a3 {+30.22/10 0.48s}
50. fxe6 {-13.78/6 0.48s} Qb2+ {+M5/100 0.25s} 51. Kd1 {-M4/100 0.10s}
a2 {+M3/100 0.030s} 52. Ke1 {-M2/100 0.016s} a1=Q# {+M1/100 0.005s, Black mates}
0-1

[/pgn]
Now, even though the network version lost, I think this is a very important milestone for Loki's LNN. This game wasn't really meant as a real test, but more to see if the network version could even play semi-descent chess... Which it did . And keep in mind that this net was only trained on 50M positions with static evaluations (by Loki 3.0/3.5) as scores, and 5 epochs or something.
What I need now, is to generate some more training data. I would ideally like to do this myself instead of using someone else's positions. Therefore I am thinking of the following plan:
All positions will be generated using fixed-depth self-play with the classical version of Loki. Then, I can set bounds on which scores to include (for example, not mate scores or +/- 900cp etc..), determine if I want drawn games to be included and so on. When a game is finished, all positions, their evaluations and the game result is appended to a list that will then be written to either an EPD-file or some kind of binary file (probably the latter though. It is both faster and more space-efficient). This will be made multi-threaded in such a way that an arbitrary amount of threads are launched, and they will each generate 1/N of the positions.

I hope to be finished with the generator soon. As soon as that is finished, I can begin training a real net. 3k elo, here I come

[amanjpro]

LNN's first game

Today, I finished the UCI-LNN implementation which means that a net can now be loaded and used by Loki
Right after I did this, I played a game against it and got completely crushed , so I thought a more reasonable opponent would be Loki 3.0. This is how the game went:
[pgn][Event "My Tournament"]
[Site "?"]
[Date "2021.06.05"]
[Round "1"]
[White "Loki LNN"]
[Black "Loki 3.0.0 64-bit"]
[Result "0-1"]
[ECO "B01"]
[GameDuration "00:01:45"]
[GameEndTime "2021-06-05T14:50:35.676 Rom, sommertid"]
[GameStartTime "2021-06-05T14:48:49.949 Rom, sommertid"]
[Opening "Scandinavian (center counter) defense"]
[PlyCount "104"]
[TimeControl "60+0.1"]

1. e4 {+0.28/7 2.1s} d5 {-0.22/9 2.1s} 2. exd5 {+0.39/7 2.0s} c6 {-0.55/10 2.0s}
3. c4 {+0.50/8 1.9s} Nf6 {-0.27/11 1.9s} 4. Nc3 {+0.58/7 1.9s}
cxd5 {-0.27/10 1.9s} 5. cxd5 {+0.46/8 1.8s} Nxd5 {-0.35/10 1.8s}
6. d4 {+0.42/7 1.8s} e6 {-0.27/9 1.7s} 7. Nf3 {+0.49/7 1.7s} Bb4 {-0.35/9 1.7s}
8. Bd2 {+0.47/7 1.6s} O-O {-0.62/9 1.6s} 9. Bc4 {+0.58/7 1.6s}
Bxc3 {-0.36/9 1.6s} 10. bxc3 {+0.37/8 1.5s} Qc7 {-0.56/9 1.5s}
11. Qe2 {+0.70/7 1.5s} Nc6 {-0.43/9 1.5s} 12. O-O-O {+0.61/6 1.5s}
a5 {+0.36/9 1.4s} 13. Rhe1 {+0.83/6 1.4s} a4 {+0.45/9 1.4s}
14. Qe4 {+0.67/6 1.4s} Ncb4 {+0.72/10 1.4s} 15. Ng5 {+0.68/7 1.3s}
Nf6 {+1.01/10 1.3s} 16. Qe2 {+0.20/8 1.3s} Nbd5 {+0.94/9 1.3s}
17. Nf3 {+0.21/7 1.2s} b5 {+1.26/10 1.2s} 18. Bxb5 {-0.09/8 1.2s}
Nxc3 {+3.45/12 1.2s} 19. Bxc3 {-1.23/8 1.2s} Qxc3+ {+4.03/12 1.2s}
20. Kb1 {-1.68/7 1.1s} Rb8 {+5.43/10 1.1s} 21. Rc1 {-3.59/7 1.1s}
Qa5 {+5.64/10 1.1s} 22. Ka1 {-3.71/6 1.1s} Rxb5 {+5.78/10 1.1s}
23. Ne5 {-4.38/6 1.0s} Bb7 {+6.33/9 1.0s} 24. g3 {-4.48/6 1.00s}
Rb4 {+6.39/8 0.99s} 25. Rc5 {-4.32/6 0.97s} Qd8 {+6.83/9 0.97s}
26. Rc4 {-4.76/6 0.94s} Ba6 {+6.72/11 0.94s} 27. Rxb4 {-3.79/8 0.91s}
Bxe2 {+7.89/11 0.91s} 28. Rxe2 {-3.96/7 0.88s} Qa8 {+8.02/10 0.88s}
29. a3 {-4.11/6 0.86s} Qh1+ {+8.53/10 0.86s} 30. Rb1 {-4.44/6 0.82s}
Qxh2 {+8.91/10 0.83s} 31. Rc1 {-4.90/6 0.80s} Qh5 {+9.01/10 0.81s}
32. Rb2 {-4.75/6 0.80s} Ne4 {+8.93/9 0.78s} 33. Re1 {-4.83/6 0.77s}
Qf5 {+9.26/9 0.76s} 34. Re3 {-5.02/6 0.74s} Rc8 {+10.02/10 0.74s}
35. Rf3 {-5.15/6 0.73s} Qh5 {+10.56/10 0.72s} 36. Ka2 {-6.23/7 0.70s}
h6 {+11.67/10 0.70s} 37. Rd3 {-5.85/7 0.68s} Nc3+ {+13.27/12 0.68s}
38. Rxc3 {-6.70/8 0.66s} Rxc3 {+13.28/11 0.66s} 39. Rb8+ {-7.20/7 0.64s}
Kh7 {+15.12/10 0.64s} 40. Kb2 {-7.45/7 0.61s} Rc7 {+16.65/11 0.62s}
41. g4 {-7.84/7 0.60s} Qh1 {+18.65/11 0.60s} 42. Nd3 {-10.42/6 0.58s}
Qd1 {+26.17/12 0.58s} 43. Ka2 {-15.18/8 0.57s} Qxd3 {+M9/8 0.57s}
44. Rb2 {-15.55/6 0.56s} Rc3 {+M7/8 0.55s} 45. Rb7 {-14.76/4 0.54s}
Rxa3+ {+M5/38 0.54s} 46. Kb2 {-M4/100 0.26s} Rb3+ {+28.04/11 0.53s}
47. Rxb3 {-17.52/7 0.52s} Qxb3+ {+28.30/9 0.51s} 48. Kc1 {-17.56/6 0.51s}
f5 {+18.72/9 0.50s} 49. gxf5 {-14.26/7 0.49s} a3 {+30.22/10 0.48s}
50. fxe6 {-13.78/6 0.48s} Qb2+ {+M5/100 0.25s} 51. Kd1 {-M4/100 0.10s}
a2 {+M3/100 0.030s} 52. Ke1 {-M2/100 0.016s} a1=Q# {+M1/100 0.005s, Black mates}
0-1

[/pgn]
Now, even though the network version lost, I think this is a very important milestone for Loki's LNN. This game wasn't really meant as a real test, but more to see if the network version could even play semi-descent chess... Which it did . And keep in mind that this net was only trained on 50M positions with static evaluations (by Loki 3.0/3.5) as scores, and 5 epochs or something.
What I need now, is to generate some more training data. I would ideally like to do this myself instead of using someone else's positions. Therefore I am thinking of the following plan:
All positions will be generated using fixed-depth self-play with the classical version of Loki. Then, I can set bounds on which scores to include (for example, not mate scores or +/- 900cp etc..), determine if I want drawn games to be included and so on. When a game is finished, all positions, their evaluations and the game result is appended to a list that will then be written to either an EPD-file or some kind of binary file (probably the latter though. It is both faster and more space-efficient). This will be made multi-threaded in such a way that an arbitrary amount of threads are launched, and they will each generate 1/N of the positions.

I hope to be finished with the generator soon. As soon as that is finished, I can begin training a real net. 3k elo, here I come

Oh that is amazing Niels... Loki is a very strong engine already and I'm sure you will get there soon

[niel5946]

Oh that is amazing Niels... Loki is a very strong engine already and I'm sure you will get there soon

Thank you Amanj

I too hope that I will get at least close to 3k, but the real problem is data generation. I think I will be needing around 100M-200M training samples which are all analyzed to some constant depth. I know c-chess-cli supports data generation, but it would be nice to also have this be done totally by Loki. Yesterday I generated ~2M positions (depth 5) with Loki 3.5.0 using c-chess-cli in around 2 hours, so I think the real dataset will take a lot of time.
I guess another big problem is that I don't know how many positions will be generated from one game, so I can't really set some amount of games (perhaps 100k) and be sure to get 100M positions out of it. Yesterday I got those 2M positions from 20k games, so around 100 positions from each game.

[niel5946]

Generating training data with search
I finally managed to get a working - and stable - dataset generator that uses the search function instead of the (HCE) evaluation
The first time I tried this, I was severely restricted by the memory of my machine. This is because the training data entries consist of 768 int8 and one regular integer which in C++ totals to 772 bytes. Therefore, I had trouble keeping all this in memory with more than 2.5M-5M positions.
Another problem I faced was that the writing of the results were extremely slow since I was saving the data as CSV files.

My solution was to firstly have a class that is responsible for the output file. This keeps the file open at all times and then writes something to it when it is told to do so. With this method I don't need to keep all results in memory and I can just write to the file in batches. Secondly, I saved the data as binary files (i chose the ".lgd" Loki-Game-Data exstension to distinguish it from regular binary files) which made writing very much faster since all the earlier string conversions aren't needed anymore.

I just finished analyzing ~72M positions from lichess.org to depth 2 with 8 threads, and it took around an hour. The reason for the low depth is just so I can see if it saved the data properly.

Code: Select all

+-------------------------------------------------------------------+
|               Loki Analysis Data Generation Results               |
+----------------------+--------------------------------------------+
| EPD datafile         | C:\\Users\\user\\Desktop\\Loki_training\\lichess_more_data\\trainingSet.epd
| Output filepath      | C:\\Users\\user\\Desktop\\lichess.lgd
| Analysis depth       | 2
| Threads              | 8
| Evaluation limit     | 39899
| Batch size           | 1000000
| Hash size (MB)       | 256
+----------------------+--------------------------------------------+
| Positions generated  | 70827767
+----------------------+--------------------------------------------+

Note the lower number of positions saved than ones actually analyzed. This is because I have made it in such a way that I can reject scores outside of some interval, mate scores in this case. This should hopefully be useful because I can train the network with very unbalanced positions early on and then use some more balanced/equal data for fine-tuning later.

I would have liked to use Loki's own self-play games for data generation, but I think I will have to limit myself to this way if Loki 4 should ever have a chance to be released

Tomorrow, I will try to train a new network with this dataset and see how it compares to the one trained on the classic evaluation function alone. Afterwards I am going to analyze all the positions to a greater depth and train a real net

[niel5946]

Staged move generation done right
Yesterday, I got staged move generation to work for the first time! The previous attempts that I have made, were all centered around the following stages:

1. Hash move, if one is found.
2. Generation and scoring of captures.
3. Good and equal captures.
4. Generation and scoring of quiets.
5. Quiets
6. Bad captures

Although this order seems reasonable enough, I never got it to work, and I think the reason for that is two-fold: 1) The bad captures needs to be identified with SEE which was done at fetch-time, and a failed SEE - resulting in trying a new capture - slowed the engine down greatly. 2) Due to the way I update the move ordering heuristics, I need the entire list of moves searched and that wasn't really possible without doing a lot of deleting and copying during move fetching. This was also a big slowdown.
Now, this time I decided to do something similar to Erik Madsen (MadChess author) with the following stages:

1. Hash move if one is found.
2. Generation and scoring of captures
3. All captures, good and bad.
4. Generation and scoring of quiets.
5. All quiets.

This is not only simpler, but faster and easier to implement. I suppose the speed gain of this method compared to the earlier one relies on bad captures being refuted very quickly. Thus, if the search function is faster at refuting them, than the fetching function is at storing them in a "bad captures list", there will be a speed gain.
I ran an SPRT test on this implementation yesterday, and this was the results (elo0 = 0, elo1 = 10):

Code: Select all

Score of Lokidev vs Loki350: 309 - 232 - 321  [0.545] 862
...      Lokidev playing White: 164 - 105 - 162  [0.568] 431
...      Lokidev playing Black: 145 - 127 - 159  [0.521] 431
...      White vs Black: 291 - 250 - 321  [0.524] 862
Elo difference: 31.1 +/- 18.4, LOS: 100.0 %, DrawRatio: 37.2 %
SPRT: llr 2.98 (101.2%), lbound -2.94, ubound 2.94 - H1 was accepted

Which is not at all bad
The implementation can be found in movestager.h and movestager.cpp in the staged-move-generation branch of Loki's repository. In the future these files will of course be in the master branch.
The only thing I need to do before merging this into master is to clean up my search_root method. I would like to add a derived class of MoveStager called RootMoveStager which will work exactly as search_root does at the moment. The only reason for this is the easier maintainability from not having two entirely different move ordering implementations.

The future of Loki
As a last thing, I feel like I should mention what Loki's future holds... I just graduated high-school in June (celebrations of this is also the reason I haven't worked much on Loki the last weeks) and because of that, I will have to start working. This in turn means that I probably won't have as much time for developing Loki as I have had previously Although it is exciting to not be in school anymore, it really saddens me that I can't work as much on Loki as I used to. Chess engine development has really become addicting
But fear not, despite of slower progress, Loki 4.0 will be released some day; And it will be a lot stronger than version 3.5

[amanjpro]

Staged move generation done right
Yesterday, I got staged move generation to work for the first time! The previous attempts that I have made, were all centered around the following stages:

1. Hash move, if one is found.
2. Generation and scoring of captures.
3. Good and equal captures.
4. Generation and scoring of quiets.
5. Quiets
6. Bad captures

Although this order seems reasonable enough, I never got it to work, and I think the reason for that is two-fold: 1) The bad captures needs to be identified with SEE which was done at fetch-time, and a failed SEE - resulting in trying a new capture - slowed the engine down greatly. 2) Due to the way I update the move ordering heuristics, I need the entire list of moves searched and that wasn't really possible without doing a lot of deleting and copying during move fetching. This was also a big slowdown.
Now, this time I decided to do something similar to Erik Madsen (MadChess author) with the following stages:

1. Hash move if one is found.
2. Generation and scoring of captures
3. All captures, good and bad.
4. Generation and scoring of quiets.
5. All quiets.

This is not only simpler, but faster and easier to implement. I suppose the speed gain of this method compared to the earlier one relies on bad captures being refuted very quickly. Thus, if the search function is faster at refuting them, than the fetching function is at storing them in a "bad captures list", there will be a speed gain.
I ran an SPRT test on this implementation yesterday, and this was the results (elo0 = 0, elo1 = 10):

Code: Select all

Score of Lokidev vs Loki350: 309 - 232 - 321  [0.545] 862
...      Lokidev playing White: 164 - 105 - 162  [0.568] 431
...      Lokidev playing Black: 145 - 127 - 159  [0.521] 431
...      White vs Black: 291 - 250 - 321  [0.524] 862
Elo difference: 31.1 +/- 18.4, LOS: 100.0 %, DrawRatio: 37.2 %
SPRT: llr 2.98 (101.2%), lbound -2.94, ubound 2.94 - H1 was accepted

Which is not at all bad
The implementation can be found in movestager.h and movestager.cpp in the staged-move-generation branch of Loki's repository. In the future these files will of course be in the master branch.
The only thing I need to do before merging this into master is to clean up my search_root method. I would like to add a derived class of MoveStager called RootMoveStager which will work exactly as search_root does at the moment. The only reason for this is the easier maintainability from not having two entirely different move ordering implementations.

The future of Loki
As a last thing, I feel like I should mention what Loki's future holds... I just graduated high-school in June (celebrations of this is also the reason I haven't worked much on Loki the last weeks) and because of that, I will have to start working. This in turn means that I probably won't have as much time for developing Loki as I have had previously Although it is exciting to not be in school anymore, it really saddens me that I can't work as much on Loki as I used to. Chess engine development has really become addicting
But fear not, despite of slower progress, Loki 4.0 will be released some day; And it will be a lot stronger than version 3.5

Good to see you around
and congrats for your graduation, I am so happy for you

Loki is currently competing in ZaTour, and I believe it needs a bit of performance boost, looking forwrad to Loki 4

[mvanthoor]

The future of Loki
As a last thing, I feel like I should mention what Loki's future holds... I just graduated high-school in June (celebrations of this is also the reason I haven't worked much on Loki the last weeks) and because of that, I will have to start working. This in turn means that I probably won't have as much time for developing Loki as I have had previously Although it is exciting to not be in school anymore, it really saddens me that I can't work as much on Loki as I used to. Chess engine development has really become addicting
But fear not, despite of slower progress, Loki 4.0 will be released some day; And it will be a lot stronger than version 3.5

Good luck, and thanks for the update.

I've been in the workforce for about 15 years now (keep repeating: "I'm not old, I'm not old, still about 27 years to go..."). The problem with work is that there's so much stuff to do and learn outside of work.

I always say I should have been born 20 years earlier. It would have been better:
- I would have been in my 20's in the 80's
- If I'd known stuff about computers back then I could have become rich (without doing it through social media)
- Lots of software still wasn't written back then, so there was lots of research (on a level I could actually understand)
- I would have been 20 years closer to retirement

[emadsen]

Now, this time I decided to do something similar to Erik Madsen (MadChess author) with the following stages:

1. Hash move if one is found.
2. Generation and scoring of captures
3. All captures, good and bad.
4. Generation and scoring of quiets.
5. All quiets.

This is not only simpler, but faster and easier to implement... Score of Lokidev vs Loki350: 309 - 232 - 321 [0.545] 862

I just graduated high-school in June (celebrations of this is also the reason I haven't worked much on Loki the last weeks) and because of that, I will have to start working.

I'm glad you found some ELO in staged move generation. You measured a gain of 31 ELO. That roughly aligns with the 39 ELO I measured in MadChess.

Congrats Neil on graduating high school! I graduated HS 28 years ago. Eh, I still feel young. Ran 12 miles this morning in the heat and humidity... Where are you located in Denmark, if you don't mind me asking? My father was born in Aarhus. I've visited Denmark a few times over the past 20 years. Beautiful country with nice people. I like the combination of Medieval history and hyper-modern design. Flat paving bricks recently placed in the hundreds year old cobblestone in Copenhagen to facilitate smooth passage of baby strollers is a good illustration of old and new living in harmony.

Yes, work takes time from your week. But it also increases your professional skills and provides a certain level of quality-of-life, so to speak. There's still time for relationships and hobbies. Best of luck in the adventures that await you.

[niel5946]

Loki is currently competing in ZaTour, and I believe it needs a bit of performance boost, looking forwrad to Loki 4

I have been checking in on how Loki has been doing in ZaTour occasionally, and I agree. I am actually considering releasing Loki 4.0 with all the new features except the neural network because of this. I believe that a working neural network evaluation will be hard to accomplish for version 4.0 because of two reasons: 1) It will take a lot of time to get right, generate proper training data and train properly. And 2) Perhaps the strength increase will actually be a little too large. What I mean by that is that I would rather have a 100 elo increase from 3.5 to 4.0 and then a 200-300 point increase from 4.0 to 5.0, instead of a 300-400 point increase directly from 4.0 to 5.0...
I don't know yet, but postponing the neural network inclusion is definitely a consideration at the moment.

I always say I should have been born 20 years earlier. It would have been better:
- I would have been in my 20's in the 80's
- If I'd known stuff about computers back then I could have become rich (without doing it through social media)
- Lots of software still wasn't written back then, so there was lots of research (on a level I could actually understand)
- I would have been 20 years closer to retirement

I don't know enough about computer science in the 80's to say whether I agree or not, but I do understand your 3rd point: As a field grows and becomes more specialized it can be hard to feel like you have an understanding of it entirely. A similar example could be physics: In the early 20th century, Einstein worked on both quantum physics and relativity, whereas it is hard to master (enough to get a big breakthrough) both subjects in today's physics. I think this tendency is both good and bad since it on one hand gives us a bigger understanding of the subject, but on the other hand, it requires lots more teamwork and trust in each other's results.

Congrats Neil on graduating high school! I graduated HS 28 years ago. Eh, I still feel young. Ran 12 miles this morning in the heat and humidity... Where are you located in Denmark, if you don't mind me asking? My father was born in Aarhus. I've visited Denmark a few times over the past 20 years. Beautiful country with nice people. I like the combination of Medieval history and hyper-modern design. Flat paving bricks recently placed in the hundreds year old cobblestone in Copenhagen to facilitate smooth passage of baby strollers is a good illustration of old and new living in harmony.

I don't even know if I could manage 4 miles, so congrats on that
I am from Copenhagen, and you're right. I love the way that Copenhagen is a modern city while not being covered in skyscrapers with glass facades. I've only visited Aarhus a few times, but it's pretty much the same there i think (although Copenhagen doesn't have a "The Old Town"). It's funny because I actually thought there had to be at least something Scandinavian when I saw your name (especially Erik with a k )

Yes, work takes time from your week. But it also increases your professional skills and provides a certain level of quality-of-life, so to speak. There's still time for relationships and hobbies. Best of luck in the adventures that await you.

Thank you very much

[niel5946]

Attempts at PSQT tuning
Over the last couple of days, I have been browsing the forum looking for new ideas to try. One of the threads that caught my eye was the one by Ed Schröder, Just an untested idea, and it made me think about my own piece-square tables. So before trying to tune them with history scores, I wanted to squeeze a little more elo out of Texel tuning.
Therefore, I began tuning them on a new, bigger dataset (~3.2M positions) and the results looked promising. The error went down a lot, so one would think that the new tables had a fair chance of gaining some elo over the old ones... But they failed miserably

The reason for this is that I didn't think about checking whether or not my data contained positions with captures, which it did. Now I'll have to write a method to resolve those positions with quiescence

Such kinds of stupid mistakes will hopefully make me think twice the next time I want to tune my eval