Something new coming down the highway

[Mike Sherwin]

...
Not at this stage as only one stat is collected and stm - other side to move is the only processing done. The sky's the limit. If one can imagine a beneficial stat that can be collected it can be factored in!

Aren't those stats going to make up an evaluation function in the end, al be it in a different way?

I can imagine these stats:
- bishop pair available
- (half-)open lines available
- castling pawn shield in tact
- pawns: passed, isolated, backward, double/triple
- center locked (knights more useful) or open (bishops more useful)

I guess that it can be open to philosophical debate. It is all part of the search function so not requiring an independant eval function. And the data is processed at the root. And yet the data comes from the entire branch of each root move.

Thanks for the data collection suggestions!

Edit: I guess that my response was a bit too quick. All the stats that you mentioned are rules of thumb that may be good or may not be accurate. Let's go over them one by one.
- bishop pair available - if good or bad will show up in the other stats as truth and not as just a rule of thumb
- (half-)open lines available - "
- castling pawn shield in tact - mainly check and checkmate stats as well as balance of null move failures and even in beta-cuts
- pawns: passed, isolated, backward, double/triple - will produce bad stats
- center locked (knights more useful) or open (bishops more useful) - will show up in the beta-cuts and mobility stats

I'm not being contrary, it is just that the whole philosophy of stats is to do away with rules of thumb and seek truth through statistical analysis. It is just a new area of exploration. Martin already mentioned a use that is separated from an evaluation in just using the stats to order moves.

[maksimKorzh]

It may be a new Diablo Countach or maybe just an old clunky Geo Metro but it is new as far as chess engines go.

About 30 years ago I had an idea to make a statistical driven search. I got part way done but had to give up on the idea because of life circumstances. When I started to program chess again around 2003 I decided on writing a more conventional chess engine that eventually turned into RomiChess. But, I always wanted to pursue my original idea. Then my mom came down with Alzheimer's and all chess activity came to a screeching halt as I had to take care of her. However, when my own health started to suffer from the strain of taking care of my mom I had no choice but to put her in a nursing home. Shortly after that I was shoveling snow and had a heart attack. I managed to get back into the house but could not make it to the phone. I must have laid there for a very long time because when I came to I had pissed and s__t myself. I was able to make it into the bathroom and clean myself off. Then I went and got into bed. I slept 20 hours a day for I do not know how long. No, I never went to the hospital. Then I remembered that my step father had a large stash of coumadin so I started to take one twice a week. Slowly my strength started to return. I lost a ton of weight.

Anyway, I have been struggling ever since to program chess once more. I would give up and then decide, no I do not want to give up. Now after all these years (thanks to help by TommyTC) I have written a very minimal example of a statistical driven search. It is not as far along as what I had 30 years ago. Thirty years ago it self played 1 e2e4 e7e5 2 f1c4 f8c5 3 g1f3 b8c6, etc. And it could more than hold its own against CM5000. I don't remember everything I did back then. It will be a rediscovery process. It understood king safety which means that I must have included checks in the statistics. This is so far the most basic idea of counting beta cutoffs and nothing more. So just consider this very first self played game as a first peek! Understand that this engine, Bricabrac, has absolutely no evaluation function whatsoever!!! Enough blah blah blah, here is the game.
[pgn][Event "Computer chess game"]
[Site "DESKTOP-HFVHK2B"]
[Date "2020.10.01"]
[Round "?"]
[White "mjshe"]
[Black "mjshe"]
[Result "*"]
[BlackElo "2400"]
[ECO "D00"]
[Opening "Hodgson Attack"]
[Time "10:15:03"]
[Variation "2...f6"]
[WhiteElo "2400"]
[TimeControl "40/7200:40/7200:7200"]
[Termination "unterminated"]
[PlyCount "65"]
[WhiteType "human"]
[BlackType "human"]

1. d4 d5 2. Bg5 f6 3. Bf4 g5 4. Bg3 f5 5. f4 Bh6 6. e3 g4 7. Bb5+ Bd7 8.
Qd3 b6 9. Nd2 Bxb5 10. Qxb5+ Qd7 11. a4 Qxb5 12. axb5 c5 13. Ke2 c4 14. h4
a6 15. b4 Nf6 16. h5 Ne4 17. Nxe4 fxe4 18. f5 Rf8 19. f6 Rxf6 20. Be5 Rf8
21. g3 Nd7 22. Rxa6 Rxa6 23. bxa6 b5 24. c3 Rf5 25. a7 Nb6 26. Bc7 Na8 27.
Be5 Kd7 28. Rh2 Rf8 29. Rf2 Rxf2+ 30. Kxf2 Ke6 31. Ke2 Kd7 32. Kd2 Ke6 33.
Ke2 *
[/pgn]
P.S. The search may still have bugs and probably does.

Mike, does your statistical search take care of squares occupied buy piece? I mean do the certain squares contribute to the overall result prediction?

Not at this stage as only one stat is collected and stm - other side to move is the only processing done. The sky's the limit. If one can imagine a beneficial stat that can be collected it can be factored in!

Understood.
The reason why I was asking is because I'm now doing something similar - building a logistic model to calculate piece weights based on PGN analysis, so instead of taking standard values for piece weights like [100, 300, 300, 500, 900] the script would produce more precise values based on the analysis of a particular PGN (with LOTS of games). Now I want to do the same for piece square table values but have no clue at the moment on how to add this piece-on-square impact to the model. I just thought maybe you've already done that so I could ask for help)

[mar]

so, if I understand you correctly: you simply use number of beta cutoffs for stm (=even plies) to resolve root move ties?
I think this could be tried in engines with full eval as well to sort non-pv root moves instead of total node count which I do now

yes, so far! Many more stats can be collected and weighed. Some that come to mind are check, checkmate, and a big one will be null move failures that indicate lots of good tactics for one side or the other. And heavily weighted bonus stats in the opening for getting pieces off the back ranks. And also yes, it can be melded with regular eval if desired. The beauty of this is that all processing is done at the root moves making it practically cost nothing!

I ran a quick test and it seems that ordering non-pv root moves based on stm's beta cutoff is 3 elo better, but within error bars (+-5), so take it with a grain of salt. nice for a first try though

[Mike Sherwin]

It may be a new Diablo Countach or maybe just an old clunky Geo Metro but it is new as far as chess engines go.

About 30 years ago I had an idea to make a statistical driven search. I got part way done but had to give up on the idea because of life circumstances. When I started to program chess again around 2003 I decided on writing a more conventional chess engine that eventually turned into RomiChess. But, I always wanted to pursue my original idea. Then my mom came down with Alzheimer's and all chess activity came to a screeching halt as I had to take care of her. However, when my own health started to suffer from the strain of taking care of my mom I had no choice but to put her in a nursing home. Shortly after that I was shoveling snow and had a heart attack. I managed to get back into the house but could not make it to the phone. I must have laid there for a very long time because when I came to I had pissed and s__t myself. I was able to make it into the bathroom and clean myself off. Then I went and got into bed. I slept 20 hours a day for I do not know how long. No, I never went to the hospital. Then I remembered that my step father had a large stash of coumadin so I started to take one twice a week. Slowly my strength started to return. I lost a ton of weight.

Anyway, I have been struggling ever since to program chess once more. I would give up and then decide, no I do not want to give up. Now after all these years (thanks to help by TommyTC) I have written a very minimal example of a statistical driven search. It is not as far along as what I had 30 years ago. Thirty years ago it self played 1 e2e4 e7e5 2 f1c4 f8c5 3 g1f3 b8c6, etc. And it could more than hold its own against CM5000. I don't remember everything I did back then. It will be a rediscovery process. It understood king safety which means that I must have included checks in the statistics. This is so far the most basic idea of counting beta cutoffs and nothing more. So just consider this very first self played game as a first peek! Understand that this engine, Bricabrac, has absolutely no evaluation function whatsoever!!! Enough blah blah blah, here is the game.
[pgn][Event "Computer chess game"]
[Site "DESKTOP-HFVHK2B"]
[Date "2020.10.01"]
[Round "?"]
[White "mjshe"]
[Black "mjshe"]
[Result "*"]
[BlackElo "2400"]
[ECO "D00"]
[Opening "Hodgson Attack"]
[Time "10:15:03"]
[Variation "2...f6"]
[WhiteElo "2400"]
[TimeControl "40/7200:40/7200:7200"]
[Termination "unterminated"]
[PlyCount "65"]
[WhiteType "human"]
[BlackType "human"]

1. d4 d5 2. Bg5 f6 3. Bf4 g5 4. Bg3 f5 5. f4 Bh6 6. e3 g4 7. Bb5+ Bd7 8.
Qd3 b6 9. Nd2 Bxb5 10. Qxb5+ Qd7 11. a4 Qxb5 12. axb5 c5 13. Ke2 c4 14. h4
a6 15. b4 Nf6 16. h5 Ne4 17. Nxe4 fxe4 18. f5 Rf8 19. f6 Rxf6 20. Be5 Rf8
21. g3 Nd7 22. Rxa6 Rxa6 23. bxa6 b5 24. c3 Rf5 25. a7 Nb6 26. Bc7 Na8 27.
Be5 Kd7 28. Rh2 Rf8 29. Rf2 Rxf2+ 30. Kxf2 Ke6 31. Ke2 Kd7 32. Kd2 Ke6 33.
Ke2 *
[/pgn]
P.S. The search may still have bugs and probably does.

Mike, does your statistical search take care of squares occupied buy piece? I mean do the certain squares contribute to the overall result prediction?

Not at this stage as only one stat is collected and stm - other side to move is the only processing done. The sky's the limit. If one can imagine a beneficial stat that can be collected it can be factored in!

Understood.
The reason why I was asking is because I'm now doing something similar - building a logistic model to calculate piece weights based on PGN analysis, so instead of taking standard values for piece weights like [100, 300, 300, 500, 900] the script would produce more precise values based on the analysis of a particular PGN (with LOTS of games). Now I want to do the same for piece square table values but have no clue at the moment on how to add this piece-on-square impact to the model. I just thought maybe you've already done that so I could ask for help)

You can deduce different piece values from a large set of positions but all you then have is an average. If you did that for all the major openings you would have an average set for each opening and that would be more accurate. If you then added reinforcement learning you could tweak those values position by position. Piece on square can also be done by reinforcement learning. Just give a slight bonus to the squares the different piece types land on of the winning side and a slight penalty to those of the losing side.

[Mike Sherwin]

so, if I understand you correctly: you simply use number of beta cutoffs for stm (=even plies) to resolve root move ties?
I think this could be tried in engines with full eval as well to sort non-pv root moves instead of total node count which I do now

yes, so far! Many more stats can be collected and weighed. Some that come to mind are check, checkmate, and a big one will be null move failures that indicate lots of good tactics for one side or the other. And heavily weighted bonus stats in the opening for getting pieces off the back ranks. And also yes, it can be melded with regular eval if desired. The beauty of this is that all processing is done at the root moves making it practically cost nothing!

I ran a quick test and it seems that ordering non-pv root moves based on stm's beta cutoff is 3 elo better, but within error bars (+-5), so take it with a grain of salt. nice for a first try though

Well, it was not a flop! But really just using one statistic is not what I had in mind. This is just a first test right? And beta_cuts[stm] - bet_cuts[otm] is superior to just beta_cuts[stm] alone. Then next to try is beta_cuts[stm] / beta_cuts[otm] which I have not done yet. My goal was just to show that there is potential, in case " I were to die tomorrow". So my demonstration was the minimalistic possible just to bring it to awareness. The quality of the demonstration game was terrible but it did show some intelligence. I'm telling the truth when I say that 30 years ago a more advanced version of what I have now held its own against CM5000. The state of this very first test is that TSCP destroys it easily. So there is much room left for improvement. And if you are already getting +3 ...

[Mike Sherwin]

so, if I understand you correctly: you simply use number of beta cutoffs for stm (=even plies) to resolve root move ties?
I think this could be tried in engines with full eval as well to sort non-pv root moves instead of total node count which I do now

yes, so far! Many more stats can be collected and weighed. Some that come to mind are check, checkmate, and a big one will be null move failures that indicate lots of good tactics for one side or the other. And heavily weighted bonus stats in the opening for getting pieces off the back ranks. And also yes, it can be melded with regular eval if desired. The beauty of this is that all processing is done at the root moves making it practically cost nothing!

I ran a quick test and it seems that ordering non-pv root moves based on stm's beta cutoff is 3 elo better, but within error bars (+-5), so take it with a grain of salt. nice for a first try though

Hi Martin, I just want to point out, in case you may have overlooked it (not that I think you did!), that collecting the b_c stat is a bit counter intuitive. It is collected as move->stat[1 - stm]++. Just making sure.

[mar]

I simply counted beta cutoffs at inner nodes (no qs) for even plies; cutoffs += (ply & 1) == 0, where root = ply 0
so not really based on stm, but I guess that it should accopmplish the same thing

[Mike Sherwin]

I simply counted beta cutoffs at inner nodes (no qs) for even plies; cutoffs += (ply & 1) == 0, where root = ply 0
so not really based on stm, but I guess that it should accopmplish the same thing

Then I did not understand your second post as Bric collects the stat with [1 - stm] after Make() then Unmake() or it can be collected with [stm] between Make() and Unmake(). If you only collect it at even plies then how can the othersides potential be factored in? I don't get it but that is okay. You should know by now that everything is a huge wrestling match for me, LOL.

[mar]

I simply counted beta cutoffs at inner nodes (no qs) for even plies; cutoffs += (ply & 1) == 0, where root = ply 0
so not really based on stm, but I guess that it should accopmplish the same thing

Then I did not understand your second post as Bric collects the stat with [1 - stm] after Make() then Unmake() or it can be collected with [stm] between Make() and Unmake(). If you only collect it at even plies then how can the othersides potential be factored in? I don't get it but that is okay. You should know by now that everything is a huge wrestling match for me, LOL.

nono, I meant that collecting at even plies will only collect beta cutoffs for stm at root, not that it can collect more stats, it was just a quick test, nothing more

[Mike Sherwin]

I simply counted beta cutoffs at inner nodes (no qs) for even plies; cutoffs += (ply & 1) == 0, where root = ply 0
so not really based on stm, but I guess that it should accopmplish the same thing

Then I did not understand your second post as Bric collects the stat with [1 - stm] after Make() then Unmake() or it can be collected with [stm] between Make() and Unmake(). If you only collect it at even plies then how can the othersides potential be factored in? I don't get it but that is okay. You should know by now that everything is a huge wrestling match for me, LOL.

nono, I meant that collecting at even plies will only collect beta cutoffs for stm at root, not that it can collect more stats, it was just a quick test, nothing more