> <i>Another question I have is: assuming that the computer programs you used for the playtesting must have assigned a preliminary value to an Archbishop, if only for when deciding during calculations whether to exchange it for something else (e.g. a queen), what was that preliminary value?</i> <p> Your questions are very much to the point. One would expect the playtest to be only meaningful when the values used are consistent, i.e. the programmed value used for deciding on trades are the same as the value that comes out based on the score percentage. But to my surprise, putting a moderately wrong value there hardly had any effect on the outcome at all. If I put Q=9.5 and C=9, and play an army with Q against an army with C, the Queen wins by ~58%. If I put Q=9.5, and C=10, the Queen still wins by 58%! The explanation is that both engines share the misconception. So one of the two sides will always try to avoid the trade, meaning that Q for C trades will be relatively rare. So the test mainly measures how much damage Q and C do to the other pieces. Although a wrong C value might lead to wrong 2-for-1 or 3-for-1 trades, the number of occasions where such a trade can be forced is relatively rare, especially if they are not exactly equal, so that one of the players will try to avoid them. So the most error-prone value assignment is actually the one where the value is exactly the same as that of another piece, or the sum of two other pieces (and wrongly so). So I usually avoid that. <p> One must not be off too much, though: If you make A < B + N the B + N side will try to avoid trading 2 minors for A, but with 4 minors of him on the board and a piece as powerful as A, he will not be able to do that, and in many games the side with A will squander his initial advantage by striving for the wrong trade. So eventually I always do the tests with the piece value in the program set to nearly the same value as what eventualy comes out. That the outcome is so insensitive to that value just means that I get the consistent value much quicker, usually already on the second try. <p> One has to be quite careful with pieces of nearly the same value, however. E.g. Knights and (unpaired) Bishops on 8x8. If I set N=3 and B=3.5, the side with the Knights will moderately win. But if I set N=3.5 and B=3 for letting the program decide what to trade, the side with the Bishops will moderately win! The piece that you tell the program is stronger will in practice be weaker. The explanation is that the program with the piece with the highest <i>programmed</i> value will try to protect it from trading against the perceived weaker piece. So if it can avert a small positional loss (of, say, 30cP) only by avoiding the trade, it will prefer the small loss. But that happens time after time during the game. The unwillingness to trade hinders the piece that is imagined stronger to do its job well, and therefore makes the piece weaker. This draws the values that have to be programmed (or used by humans to determine which trades are favorable) very close together. You might want to protect a Bishop against trading for a Knight, but not at all cost, and not even at a cost that is a large fraction of the intrinsic value difference, as you likely will have to do it several times during a game. This is an example of where piece values are influenced by the composition of the opponent army, that goes beyond simple addition of values for individual pieces. <p> > <i>Decades ago I was somewhat into computer programming, and found a lot of time was involved, and eventually a kind of aversion developed. </i> <p> Well, nowadays using software is as far removed from programming as watching television is from building one. And it can be quite interesting to see on the screen how the programs battle each other in a variant, when you set them to a time control that is a good compromise between being boring and driving you crazy. At least, I enjoy it a lot. Often it is much more interesting than watching a soccer game! :-)