Redundant knight

[zullil]

I know that many engines apply a penalty for a redundant rook, SF for example. But I wonder how many engines would apply the somewhat less obvious penalty for a redundant knight?

Pieces with same piece type, when repetitive, are of course due some penalty, as they do not coordinate quite well among themselves; in any case, different piece types coordinate better.

This makes little sense to me, especially for rooks. Two rooks can work very well in forming a "battery", that can control an open file, for example.

Perhaps I misunderstand "redundancy", especially if "many engines apply a penalty for a redundant rook".

[Lyudmil Tsvetkov]

I think your views on this are way too simplistic. As the Queens vs Knights end-games show, Knights cooperate much better with each other than mixed pieces do.

There is a well-known reason for penalizing a pair of Knights: it has no mating potential. How important this is depends on the total number of Pawns, though.

The first position you show is also favorable for white because of the Pawn spread. Pawns on both wings is an advantage against low-speed pieces like Knights per se, whether they come in pairs or not. Give white an f-Pawn in stead of a b-Pawn, and he doesn't stand any winning chances at all. Even shifting the Pawn to the c-file already seems to make the position quite hopeless for white's winning ambitions: the Knights can block the passer while protecting each other, and protect their own g-Pawn at the same time, leaving no weakness for the Rook to attack.

So this doesn't seem to have anything to do with redundancy. Just with Pawn structure evaluation and the absence of sliding pieces that can easily switch wing. Replace one of the Knights by a Modern Elephant, (which moves one square, or jumps two, both diagonally), and you will not be off much better, (if not much worse), despite the facts that the Knight and Elephant have completely different moves.

I think we agreed that 3 queens do better vs 7 knights than against 3 knights and 4 bishops. There was sufficient game evidence for that. Jerry Donald also posted that 7 bishops perform better than 7 knights vs 3 queens.

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.

[Lyudmil Tsvetkov]

I know that many engines apply a penalty for a redundant rook, SF for example. But I wonder how many engines would apply the somewhat less obvious penalty for a redundant knight?

You are wrong on both of your pre-supposition, so all the rest is not even worth reading:
1. stockfish does NOT have a redundant rook term. it was shown to be completely useless in testing and removed. In discocheck, I also arrived at the same conclusion.
2. knight redundancy is a seriously dubious concept. HGM has already explained this to you in lengthy details (elephantiasis effect), but as usual you did not listen, and you continue trying to teach your misconceptions anyway...

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.

Harm explained nothing, it is still not certain if 7 knights are better than 3 queens, however, the above debate has nothing to do with penalising 2 knights in a normal game, as 2 knights never defend each other the way a larger number of minor pieces, 7 knights for example, would. Those are simply differences of scale. I am talking about a normal game situation.

[Lyudmil Tsvetkov]

I know that many engines apply a penalty for a redundant rook, SF for example. But I wonder how many engines would apply the somewhat less obvious penalty for a redundant knight?

Pieces with same piece type, when repetitive, are of course due some penalty, as they do not coordinate quite well among themselves; in any case, different piece types coordinate better.

This makes little sense to me, especially for rooks. Two rooks can work very well in forming a "battery", that can control an open file, for example.

Perhaps I misunderstand "redundancy", especially if "many engines apply a penalty for a redundant rook".

This is about assessment of different factors. 2 rooks deserving a bonus for an open file is quite apart from 2 rooks being redundant, as for example a pawn could be isolated and form part of the king shelter, or bishop be outposted and have very little mobility at the same time.

We are talking here of imbalance evaluation, and in most cases, like in the position of 3 minors vs 2 rooks, because of their bad coordination in comparison to the 3 minors, the rooks will quite probably never be able to form a doubled rook battery. So that redundancy only accentuates deficiencies.

[Lyudmil Tsvetkov]

[d]4r1k1/1pp2pp1/p1b1n2p/8/8/1PQ1N2P/P4PP1/6K1 w - - 0 1
2 piece configurations that lack any form of redundancy. A queen is never redundant with a knight.
Rook, bishop and knight are never redundant among themselves, as they control different squares.

[d]5bk1/1p1q1pp1/p5bp/8/2P5/1P2NBBP/P4PP1/2R3K1 w - - 0 1
2 bishops are never redundant with a knight or rook, but are redundant with a queen, so black deserves above a small penalty for partial queen-bishop redundancy. (you could penalise just one of the bishops, so partial redundancy could receive just a single penalty for a specific configuration, i.e. you do not need to penalise twice the queen in QRR, just one full rook redundancy and one partial queen-rook redundancy penalty)

The amount of scepticism how useful this actually is is really astounding, but redundancy really plays a very big role in chess. The fact that someone tried to apply redundancy and failed does not mean that it is inapplicable. You simply need the right approach.

But again, to the unbelievers, there were times in chess, prehistoric ones, but also more recent, when engines evaluated only material and passers, and did very bad. Until some years ago passers even did not get a special bonus for rank. Most thought this to be stupid, but it proved to be completely not like that. It is the same with different forms of redundancy: they are real, they are tangible and useful, and could be successfully implemented, after many failed attempts of course, but you need to open your eyes.

[zullil]

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

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

[Lyudmil Tsvetkov]

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

Thanks Louis.

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.

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