Redundant knight

[Lyudmil Tsvetkov]

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.

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.

Can you point to the line of code that does redundancy evaluation in SF? I can't find it.

Your same-vein messages are redundant - pun not intended.

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;
 

[arjuntemurnikar]

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.

Hate it or not, you have to live with it. Its real and its important.

"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).

[Joerg Oster]

Can you point to the line of code that does redundancy evaluation in SF? I can't find it.

Here https://github.com/mcostalba/Stockfish/ ... 74812db458 is the commit where the RedundantMajor Value has been dropped and merged into the material imbalance tables.
I guess, Lyudmil is referring to that older piece of code.

[arjuntemurnikar]

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.

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.

Can you point to the line of code that does redundancy evaluation in SF? I can't find it.

Your same-vein messages are redundant - pun not intended.

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;
 

Please don't lecture us about code.

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! )

[Lyudmil Tsvetkov]

Can you point to the line of code that does redundancy evaluation in SF? I can't find it.

Here https://github.com/mcostalba/Stockfish/ ... 74812db458 is the commit where the RedundantMajor Value has been dropped and merged into the material imbalance tables.
I guess, Lyudmil is referring to that older piece of code.

That is right, Joerg.

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

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.

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.

[arjuntemurnikar]

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.

Pretty much sums up your posts on talkchess:

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...

[arjuntemurnikar]

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.

Pretty much sums up your posts on talkchess:

Talk like you have expert understanding of a subject which in reality you understand nothing about.

To sum up:
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!

[Lyudmil Tsvetkov]

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.

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.

Can you point to the line of code that does redundancy evaluation in SF? I can't find it.

Your same-vein messages are redundant - pun not intended.

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;
 

Please don't lecture us about code.

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! )

Why do you need a gigantic undertaking for 2 or 3 elo at most?
Those are your words, but I say there are more than 50 elo in imbalance and piece values, I have absolutely no doubt about that.

I congratulate also Joerg for his efforts, but tuned imbalance can not substitute for everything. I repeat it again: you can never do queen vs 3 pieces with the imbalance tables, never. Joerg claimed to have simplified his ad-hoc rule when he improved the imbalance tables, but you now see SF fully does not understand queen vs 3 pieces, so that the improvement went somewhere else. You do not know quite what you are doing with the imbalance tables.

The same is true for merging redundant rook into imbalance: are you sure imbalance now handles that better? You can not in any way, you do not know where the change has gone, besides, removing failed at LTC.

I will tell you simply why you can not do queen vs 3 pieces in the imbalance tables, but you will not understand me. Queen imbalances involve imbalances like Q vs R+minor and Q vs 2Rs, which are by far the most frequent ones. It also includes imbalances like Q vs 3 pieces (3 minors, R+2 minors or 2Rs+ minor), which are rare. How are you going to tune Q vs 2Rs and Q vs R+minor and Q vs 3 pieces at the same time with the same parameter values in the same tables, when in Q vs 2Rs or Q vs R+minor you will have to leave all piece values unchanged, while in Q vs 3 pieces the R, B and N value should go up, and very much at that?

Please tell me how, but first think a bit? Simply impossible. When you tune the whole, you will tune for the most frequent case, and that will leave Q vs 3 pieces imbalance unresolved for ever. Do you understand now?

That is why I have been urging and am urging Joerg again to resubmit a corrected Q vs 3 pieces patch to fishtest. You simply must have an ad-hoc rule for Q vs 3 pieces, there is no other way. Besides, imbalance tables and Q vs 3 pieces imbalance are totally unrelated.

And Arjun, one last thing to you: I tell you again, it is knowledge that scales at longer TC and with bigger hardware. Hardware power increases with each year, what are you going to do at longer TC and huge hardware but calculate more terms? That is the right thing to do, that is why you have much time and big hardware. More knowledge will avoid randomness. If you have few terms, you simply calculate more, or much more, but, please note, random lines. Random lines usually bring you nothing, you need specific lines.

I thought beancounting has already been discarded.

[Lyudmil Tsvetkov]

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.

Pretty much sums up your posts on talkchess:

Talk like you have expert understanding of a subject which in reality you understand nothing about.

To sum up:
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!

I bet you were failed on your last exam, or was it a D-?

[hgm]

I think we agreed that 3 queens do better vs 7 knights than against 3 knights and 4 bishops.

'We' as in referring to yourself, I suppose, because I never agreed to any such thing.

There was sufficient game evidence for that. Jerry Donald also posted that 7 bishops perform better than 7 knights vs 3 queens.

I don't think this can be based on anything, as to my knowledge there doesn't exist any engine equipped with an evaluation that understands this end-game. It seems very easy for the Queens to draw against 7 Bishops: just sacrifice the Queens one on one against the Bishops on the minority color, and the remaining 4 Bishops have no mating potential. But engines not aware of that fact would of course never attempt it.

It is also about pawn spread, but in 80-90% of cases pawns will be spread on both wings, so this is the natural state of things. Having pawns just on one wing is an exception. With pawn spread on both wings, 2 knights perform even worse than a single knight, so redundancy is felt.

Grouping things together that need different treatment is a very bad idea. Evaluations must be precise and accurate, if you want an engine to ever rise above the level of micro-Max. An engine that cannot see the difference between the 10-20% where having Knights is good and the 80-90% where having them is bad, will almost always be suckered by an opponent that does know that difference into the 10-20%. The 10-20% is only "the natural state of things" when both players are aware of the difference. It won't remain so when one of the players is ignorant.

I have seen that in my Xiangqi engine. When it did not know the rules for perpetual chasing, only 1.5 of the games ended in a perpetual chase (declared a loss by the GUI). So I figured perpetual chasing was too rare to worry about it. But once I programmed the engine to recognize it, playing against the version that didn't resulted in 18% of the games being won by perpetual chasing. Because the engine that did know about it just suckered the engine that didn't into chasing him.