I really appreciate your many posts concerning evaluation. Although I haven't read each one---there are quite a few, after all ---I've thought about many of them.
Now please don't take this the wrong way, but the main effect of your posts has been to convince me that this is not the way to go. Too many terms, too much hidden overlap (non-orthogonality), too many artifacts of the human approach to chess, motivated by our very limited search abilities.
At a fundamental level, it seems to me that evaluation comes down to mobility and attack. Even the material value of pieces is simply more or less an encapsulation of their mobilities. Admittedly this is overly simplistic (and focused on the opening and midgame), but a position is good for us if we can move to lots of squares and if we attack a lot of enemy material. After all, the goal of the game is to reduce the opponent's mobility to zero while simultaneously attacking his most valuable piece!
You've almost inspired me to revisit my primitive engine and, after improving the basic move generation and search, to focus on an evaluation based on mobility + attacking. Mostly as an academic exercise, since any engine I create would be just for fun (and also pretty weak).
Redundant knight
Moderators: hgm, Rebel, chrisw
-
- Posts: 204
- Joined: Tue Oct 15, 2013 10:22 pm
- Location: Singapore
Re: Redundant knight
I think this is already covered by the imbalance table, if not it should be.
There is no reason for the redundant piece evaluation term -- it is simply redundant -- pun intended.
There is no reason for the redundant piece evaluation term -- it is simply redundant -- pun intended.
Can you point to the line of code that does redundancy evaluation in SF? I can't find it.Lyudmil Tsvetkov wrote: So when was rook redundacy removed from SF?
The last time I checked SF code, a month ago, it was still there. I also know that at the end of last year someone submitted a test to remove redundant rooks, and it failed. This is on the framework history page.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: Thanks
Thanks Louis.zullil wrote:I really appreciate your many posts concerning evaluation. Although I haven't read each one---there are quite a few, after all ---I've thought about many of them.
Now please don't take this the wrong way, but the main effect of your posts has been to convince me that this is not the way to go. Too many terms, too much hidden overlap (non-orthogonality), too many artifacts of the human approach to chess, motivated by our very limited search abilities.
At a fundamental level, it seems to me that evaluation comes down to mobility and attack. Even the material value of pieces is simply more or less an encapsulation of their mobilities. Admittedly this is overly simplistic (and focused on the opening and midgame), but a position is good for us if we can move to lots of squares and if we attack a lot of enemy material. After all, the goal of the game is to reduce the opponent's mobility to zero while simultaneously attacking his most valuable piece!
You've almost inspired me to revisit my primitive engine and, after improving the basic move generation and search, to focus on an evaluation based on mobility + attacking. Mostly as an academic exercise, since any engine I create would be just for fun (and also pretty weak).
And I thought I posted just a few messages...
It depends on how you look upon it, I understand that very well. Different persons see different things. Nothing bad about that. But we are talking here how to perfect things. You are completely right, mobility is the most important thing (I would say immediately after space advantage ), but mobility comes in different ways: it comes with attacking, it comes with space, it comes with pawn features and it comes with imbalance evaluation. As mobility is reflected and substantiated in different ways, you can have a whole grasp of it only if you consider those different ways. And the more ways you consider, the closer you are to understanding mobility in-depth.
Now, I started hating that word - orthogonal. Lucas talks about orthogonality, Arjun talks about orthogonality, and now you also started doing this. You do not know what is orthogonal and what not until you test it. However, I completely agree that you do not need too many features in eval; but you need the most important ones. You can certainly get rid of unimportant terms.
I tell you again: the more terms you have in eval in a resonable way, the better, as they omit less possibilities of game development. This has been proven in engine history to be true, but people are always suspicious and unaccepting of new suggestions.
So you have an engine, hope to play a game against it one day.
Your messages and especially output also always inspire me.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: Redundant knight
Your same-vein messages are redundant - pun not intended.arjuntemurnikar wrote:I think this is already covered by the imbalance table, if not it should be.
There is no reason for the redundant piece evaluation term -- it is simply redundant -- pun intended.
Can you point to the line of code that does redundancy evaluation in SF? I can't find it.Lyudmil Tsvetkov wrote: So when was rook redundacy removed from SF?
The last time I checked SF code, a month ago, it was still there. I also know that at the end of last year someone submitted a test to remove redundant rooks, and it failed. This is on the framework history page.
Imbalance will never take account of this, as this is a special term; in the same way as it will never take account of the queen vs 3 pieces imbalance.
It seems that I know SF code better than you and Lucas.
Please take a look at the below link:
http://tests.stockfishchess.org/tests/v ... 45a2478d18
Code: Select all
// Scale factors used when one side has no more pawns
35 35  const int NoPawnsSF[4] = { 6, 12, 32 };
36 36 
37  - // Polynomial material balance parameters
38  - const Value RedundantQueen = Value(320);
39  - const Value RedundantRook = Value(554);
40 37 
41 38  // pair pawn knight bishop rook queen
42 39  const int LinearCoefficients[6] = { 1852, -162, -1122, -183, 105, 26 };

@@ -102,6 +99,8 @@ namespace {
102 99  int imbalance(const int pieceCount[][PIECE_TYPE_NB]) {
103 100 
104 101  const Color Them = (Us == WHITE ? BLACK : WHITE);
102  + const Value RedundantQueen = Value(320);
103  + const Value RedundantRook = Value((pieceCount[Us][PAWN] + pieceCount[Them][PAWN]) * 40);
105 104 
106 105  int pt1, pt2, pc, v;
107 106  int value = 0;
-
- Posts: 204
- Joined: Tue Oct 15, 2013 10:22 pm
- Location: Singapore
Re: Thanks
Hate it or not, you have to live with it. Its real and its important.Lyudmil Tsvetkov wrote: Now, I started hating that word - orthogonal. Lucas talks about orthogonality, Arjun talks about orthogonality, and now you also started doing this. You do not know what is orthogonal and what not until you test it. However, I completely agree that you do not need too many features in eval; but you need the most important ones. You can certainly get rid of unimportant terms.
"You do not know what is orthogonal and what not until you test it."
This statement is wrong. Testing tells you nothing about orthogonality. You have to figure that out by understanding the code. Testing only tells if you if a patch is good or bad. It may be good but it may introduce (in inadvertent ways) a redundant term that just so happens to fill a gap in the already existing code that was incomplete in the first place. So simply testing without thinking twice can by very misleading. That is why Marco does not accept every patch that passes.
So it is good that people are suspicious about some of your ideas. That means they are thinking about it (something you don't generally do).
-
- Posts: 937
- Joined: Fri Mar 10, 2006 4:29 pm
- Location: Germany
Re: Redundant knight
Here https://github.com/mcostalba/Stockfish/ ... 74812db458 is the commit where the RedundantMajor Value has been dropped and merged into the material imbalance tables.arjuntemurnikar wrote:Can you point to the line of code that does redundancy evaluation in SF? I can't find it.
I guess, Lyudmil is referring to that older piece of code.
Jörg Oster
-
- Posts: 204
- Joined: Tue Oct 15, 2013 10:22 pm
- Location: Singapore
Re: Redundant knight
Please don't lecture us about code.Lyudmil Tsvetkov wrote:Your same-vein messages are redundant - pun not intended.arjuntemurnikar wrote:I think this is already covered by the imbalance table, if not it should be.
There is no reason for the redundant piece evaluation term -- it is simply redundant -- pun intended.
Can you point to the line of code that does redundancy evaluation in SF? I can't find it.Lyudmil Tsvetkov wrote: So when was rook redundacy removed from SF?
The last time I checked SF code, a month ago, it was still there. I also know that at the end of last year someone submitted a test to remove redundant rooks, and it failed. This is on the framework history page.
Imbalance will never take account of this, as this is a special term; in the same way as it will never take account of the queen vs 3 pieces imbalance.
It seems that I know SF code better than you and Lucas.
Please take a look at the below link:
http://tests.stockfishchess.org/tests/v ... 45a2478d18
Code: Select all
// Scale factors used when one side has no more pawns 35 35  const int NoPawnsSF[4] = { 6, 12, 32 }; 36 36  37  - // Polynomial material balance parameters 38  - const Value RedundantQueen = Value(320); 39  - const Value RedundantRook = Value(554); 40 37  41 38  // pair pawn knight bishop rook queen 42 39  const int LinearCoefficients[6] = { 1852, -162, -1122, -183, 105, 26 };  @@ -102,6 +99,8 @@ namespace { 102 99  int imbalance(const int pieceCount[][PIECE_TYPE_NB]) { 103 100  104 101  const Color Them = (Us == WHITE ? BLACK : WHITE); 102  + const Value RedundantQueen = Value(320); 103  + const Value RedundantRook = Value((pieceCount[Us][PAWN] + pieceCount[Them][PAWN]) * 40); 105 104  106 105  int pt1, pt2, pc, v; 107 106  int value = 0;
There are a number of things wrong with your post above.
1. You point to a 3rd party repo of stockfish, not the official one by Marco.
2. Not only is it a 3rd party repo, it is hopelessly out of date (8+ months!!)
3. You point to a test that is incomplete and has a <0.1 p-value, so it is completely unreliable.
Here is the correct commit that removes the redundant terms: https://github.com/mcostalba/Stockfish/ ... fe7a3b467b
and here is the followup: https://github.com/mcostalba/Stockfish/ ... 74812db458
So as you can see -- these terms are easily incorporated by the material imbalance table.
The Q vs 3 minors are also incorporated into the table. It is just a matter of tuning them. I don't know why these misconceptions are flying around that Q vs 3 minors is a "special case" that cannot be part of the table. That is simply wrong!
Unfortunately, since the array is quite large, it is impossible to do the tuning in one CLOP session. So Joerg is probably breaking it down into multiple sessions for each piece type, but this creates problems as all the terms are inter-related. There may also be the possibility that he is running into local maximas.
The material imbalance tuning will take a very very long time as it is a gigantic undertaking, so please be patient. (...and kudos to Joerg for even daring to attempt it on his own! )
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: Redundant knight
That is right, Joerg.Joerg Oster wrote:Here https://github.com/mcostalba/Stockfish/ ... 74812db458 is the commit where the RedundantMajor Value has been dropped and merged into the material imbalance tables.arjuntemurnikar wrote:Can you point to the line of code that does redundancy evaluation in SF? I can't find it.
I guess, Lyudmil is referring to that older piece of code.
Thanks very much.
Code: Select all
Short TC 15+0.05
ELO: 1.93 +-2.1 (95%) LOS: 96.6%
Total: 40000 W: 7520 L: 7298 D: 25182
Long TC 60+0.05
ELO: -0.33 +-1.9 (95%) LOS: 36.5%
Total: 39663 W: 6067 L: 6105 D: 27491
So that redundant major was removed although it did not pass the test...
Besides, I have to mention that, as far as I understood, in SF RR, QR and QRR got exactly the same penalty, which is a bit of nonsense for me. It should have been the following way:
RR - full penalty
QR - half penalty
QRR - one and half penalty
So that even in SF at LTC this was meaningful. I guess the same would be true of redundant knight.
-
- Posts: 204
- Joined: Tue Oct 15, 2013 10:22 pm
- Location: Singapore
Re: Redundant knight
Pretty much sums up your posts on talkchess:Lyudmil Tsvetkov wrote: Please see the difference at short and long TC. +220 games for no redundant rook at STC, -40 games at LTC! So that, I repeat again, knowledge scales well. At even longer TC, this would be even more evident.
Talk like you have expert understanding of a subject which in reality you understand nothing about.
In this case, it is statistics.
I bet Joerg is laughing at you right now, but he is probably too kind to say it...
-
- Posts: 204
- Joined: Tue Oct 15, 2013 10:22 pm
- Location: Singapore
Re: Redundant knight
To sum up:arjuntemurnikar wrote:Pretty much sums up your posts on talkchess:Lyudmil Tsvetkov wrote: Please see the difference at short and long TC. +220 games for no redundant rook at STC, -40 games at LTC! So that, I repeat again, knowledge scales well. At even longer TC, this would be even more evident.
Talk like you have expert understanding of a subject which in reality you understand nothing about.
1. You are not a titled chess player, or a master-level player, but you act like you have a GM-level understanding of chess.
2. You are not a programmer, and you claim that you do not understand code, yet you lecture programmers about code.
3. You haven't the faintest clue about statistics, yet you are happy to point out how fishtest is based on incorrect statistics.
I was searching the internet for the correct psychological term for this behavior and found this -- https://en.wikipedia.org/wiki/Illusory_superiority
Enjoy!