Prior to these CCRL and CEGT numbers being available I ran a Stockfish 12 vs. Stockfish 11 100-game tournament at Blitz time controls (5 mins/game + 6 secs/move increment starting at move 1) over several nights. These were the results:

Stockfish 12: +28, =61, -10; 0.590 fractional score, 59.0% scoring %

Stockfish 11: +10, =61, -28; 0.410 fractional score, 41.0% scoring %

So Stockfish 12's.0.590 fractional score translates into a +65 Elo rating point gain.

However, I did notice a seemingly large number of games lost on time by both engines, 16, i.e. 16% of the total number of games played. Most of these were won by Stockfish 12, 14 of them or 87.5% While some losses on time can be expected, the disproportionate amount of games lost on time by Stockfish 11 might indicate that there is an inherent defect in Stockfish 11's time management function which was corrected in Stockfish 12. So the tournament results might not be a true indication of using the NNUE-based evaluation function in Stockfish 12 compared to using the classic hand-crafted evaluation function in Stockfish 11.

So, excluding the losses on time by both engines, the time control loss-adjusted results were:

Stockfish 12: +14, =61, -7; 0.542 fractional score, 54.2% scoring %

Stockfish 11: +7, =61, -14; 0.458 fractional score, 45.8% scoring %

So Stockfish 12's time control loss-adjusted 0.542 fractional score translates into "only" a +30 Elo rating point gain.

I don't know if CCRL and/or CEGT count time forfeits for the engine that lost on time or not (I suspect they do), and after all, a faulty time management function is a problem for the engine and, if it results in a time forfeit, so be it. But in this instance, if we are interested in comparing the results of having an NNUE-based evaluation function with having a classic, hand-crafted evaluation function, then whether one of the engines has a faulty time-management function needs to be taken into account.

Evaluation between [-0.00] to [+0.49]: Even chances for both sides.

Evaluation between [+0.50] to [+0.99]: White has a slight advantage.

Evaluation between [+1.00] to [+1.99]: White has a significant advantage.

Evaluation between [+2.00] & up: White has a winning advantage.

The same but with negative evaluations means that the evaluations refer to Black.

So in your position it's not unreasonable for White to have a slight advantage given that he's a pawn up which, all other factors being equal, would likely earn him a [+1.00] evaluation. But all other factors are not equal; there are BOCs on the board and Black's king can get to c7 and prevent White's king from supporting his Pa6. And, of course, White's LSB cannot threaten Black's pawns on dark squares.

So Stockfish 11's evaluation of [+0.60] is not unreasonable. Also consider that Stockfish's evaluations are typically slightly higher than other engines'. For example, I had Houdini 6 and Komodo 12.3 analyze the same position with 5-piece Syzygy tablebase support. At d=36 and about 2.5 hour of analysis in my ancient 32-bit computer Houdini 6 evaluated the position at [+0.19] for it's 3 "top" moves, 1. Bd5, 1.Kd3, and 1.Be4, indicating that the position indicates equal chances for both sides, but not necessarily a draw (although in this position that's the most likely outcome). Given the moves identical evaluations the order that the moves are listed is just the order that it found them in its search tree transversal.

But Komodo 12.3 evaluated the position at d=83 (!) and slightly less than 3 hours of analysis at [+0.71] for it's 3 "top" moves, 1.Ba8, 1.Kd3, and 1.Kb5, again listing them in the order that it found them in its search tree. And it had evaluated those same 3 moves at [+0.92] since d=55, and [+0.96] from d=11 to d=54. Still, all those evaluations indicate that Komodo 12.3 considered that in this position White has a slight advantage, consistent with Stockfish's evaluation.

And this is fastest by far I've ever seen Komodo reach such search depths. It reached d=54 in only 29 secs, maybe even faster than Stockfish could have. And it reached d=60 in only 3 mins. I have no idea why.

Tonight I'll have Stockfish 11 and Stockfish 12 analyze the position under the same conditions and I'll post the results tomorrow.

In situations like these when I run analyses using multiple engines I typically calculate a ratings-weighted average of the 3 engines' evaluations to try to remove some of the engine's evaluation biases. The ratings are based on the latest CCRL and CEGT engine vs. engine tournament results and in turn are the engines' average ratings at the different time controls used. So in this case Stockfish 11's evaluation would be given a greater weight than either Houdini 6's or Komodo 12.3's and a likely more accurate absolute evaluation would be [+0.48], indicating even chances for both sides.

40/120 (CEGT) 3481 N/A(1) N/A(1)

40/20 (CEGT) 3507 3545(2) +38(3)

40/15 (CCRL) 3481 3516 +115

40/04 (CEGT) 3587 N/A(1) N/A(1)

40/02 (CCRL) 3599 3680(2) +81(3)

Note 1: Not Available. The CEGT 40/120 and 40/04 engine tournaments were completed before Stockfish 12 was released.

Note 2: For 1-CPU version of the engine. I have no idea why a 4-CPU version of the engine was not used.

I'm wondering if there are any programs that use Monte Carlo Methods. I hypothesize that a program using Monte Carlo methods on the position would give a zero or near zero evaluation.

Now we can wait to see if the 150 Elo rating point advantage for Stockfish 12 NNUE holds up after unbiased engine vs. engine tournaments like CCRL (http://computerchess.org.uk/ccrl/) and CEGT (http://www.cegt.net/) incorporate it into their various time control tournaments.>

Yes. LeelaC0 and all (I believe) the neural network-based chess engines such as Fat Fritz, Lelenstein, Allie, Stoofvless, Scorpio, etc. use Monte Carlo Tree Search (MCTS) instead of Minimax (MMax) + Alpha/Beta pruning + Search Tree Pruning Heuristics to select the best move from a given position. Unfortunately they all require 64-bit computers and I only have (but hopefully not for long) a 32-bit computer so I can't run any of them.

But Komodo provides an option to use MCTS instead of MMax to select the best move to play and come up with an evaluation of its top move. Currently Komodo 14 with MMax is somewhat stronger than Komodo 14 with MCTS (43 Elo rating points), the first being rated at 3419 and the second at 3376 in the latest CCRL 40/15 engine vs. engine tournament, both ratings being for the 4-CPU version, but the rating difference between the two for the same Komodo version is getting smaller, although not monotonically.

I unfortunately can't run any Komodo version higher than 13 on my computer because of my 32-bit limitation but tonight I will run a test case with Komodo 12.3 MMax (which is what I used with their analysis of you initial position) and Komodo 12.3 MCTS and see what results I get.

Some caveats. Unlike chess engines using minimax and have evaluation functions expressed in centipawns in the range [-128, +128] (or so, the [ ± 128] evaluations are an artifact of the information provided by the Syzygy evaluations and depend on how the specific chess engine interprets them), chess engines using MCTS evaluate each candidate move by calculating the scoring probability of each move (their documentation usually call it the winning probability but I don't believe that's right, it also includes the probability of drawing) in the range of [0, 1]. Komodo MCTS then "estimates" what an equivalent "centipawn" evaluation would be. And the mapping between scoring probability and centipawn evaluation, at least for LeelaC0, is not a simple one (see http://chessforallages.blogspot.com... if you are curious and/or masochistic). It looks like a brace ( "}") lying on its side and it's not monotonic. So you might need to take a leap of faith when engines that use

And the concept of search depth is not the same for Komodo MMax and Komodo MCTS since the latter does not use iterative deepening, so Komodo MCTS also "estimates" what an equivalent "search depth" would be if it was using MMax.

<Ron> And now for another post that I think might be more puzzling than informative. I ran more tests and, no, Stockfish is still, at least most of the time, the champion in terms of shortest time to reach a given depth, or at least Stockfish 11 is. For example, Stockfish 12 was slower than Komodo 12.3 (!); that was unexpected. It took Komodo 3.00 mins to reach d=60 but it only took Stockfish 11 0.53 mins and Stockfish 12 0.47 mins to reach the same depth. And it took Komodo 5.47 mins to reach d=70 but it only took Stockfish 11 2.23 mins and Stockfish 12 1.72 mins to reach the same depth. So far, so good as far as determining the "king of the search depth".

But Stockfish 12 "hit the wall" at d=75. It took it 8.17 mins to reach d=74 while it took Komodo 8.80 mins and Stockfish 11 4.05 mins to reach the same depth. But then it took Stockfish 12 147.10 mins (more than 2 hours!) to reach d=75 while it only took Komodo 12.3 11.48 mins and Stockfish 11 4.75 mins to reach the same depth. Stockfish 12 then resumed its steady increase, needing only 0.47 mins to go from d=71 to d=72 and 0.67 mins to go from d=72 to d=73. There is much about chess engines that I don't know. Then again, how often are you going to find positions that allow you to have Stockfish reach d=70+ in a reasonable amount of time? So it might be a moot point.

BTW, Houdini 6 hit a similar wall at d=35. It took it 13.83 mins to reach d=34 but it then took it 149.53 mins (almost 2.5 hours!) to reach d=35. But then it took it only an additional 2.37 mins to reach d=36. Unfortunately I stopped it here so I don't know if it would have hit another wall at a higher search ply.

Maybe Houdini 6 and Stockfish 12 just decided to take a break. But at least Stockfish 12 was more "accurate". It's evaluation was [0.00] since d=19 for its "top" 3 moves (1.Kd3, 1.Be4, and 1.Bd5) and remained at [0.00] up to d=82. So it better reflected the results (draws after all reasonable moves) that FinalGen indicated.

And how did Komodo and the Stockfishes get to such a high search depth so quickly? After thinking about it a little bit I thought that it had to do with the relatively fixed nature of the position.

click for larger view

The k-side pawns are fixed and immobile. From the perspective of calculating the number of candidate moves at each search depth they might as well not be there, it would be as though the position was this one:

click for larger view

Well, for engines this didn't seem to be the case, at least for this position. It took Houdini 6 only 0.20 min to reach d=30 in the original position but 11.02 mins to reach d=30 in the simplified position with 4 less pawns. Similarly it took Komodo 12.3 only 0.25 mins to reach d=60 in the original position but 1.33 mins to reach d=60 in the simplified position; it took Stockfish 11 only 0.10 mins to reach d=60 in the original position but 3.62 mins to reach d=60 in the simplified position; and it took Stockfish 12 just 0.47 mins to reach d=60 in the original position but 15.68 (!) mins to reach d=60 in the simplified position. And note that in this position Komodo 12.3 was faster than either Stockfish, it took it only 1.33 mins to reach d=60 but it took Stockfish 11 and Stockfish 12 much longer, particularly Stockfish 12, to do the same.

And the conditions were the same; same computer with 4 GB RAM, 2 cores/engine (I have only 4 cores, and I ran 2 analyses concurrently), and a 512 MB hash table for each engine, I cleared the hash table prior to starting each analysis and had no other applications open other than Windows Explorer and two instances of Arena 3.5, one for each engine.

Two other items of possible interest; at d=30 Houdini's hash table was 41% full and it had 15 tablebase hits, Stockfish 11 and Stockfish 12 at d=60 had their hash tables 41% and 63% full respectively, and each had 4 tablebase hits. But at d=30 Komodo indicated its hash table was completely empty and it had 17 tablebase hits. Which makes sense, with only 5 pieces and 5-piece Syzygy tablebase support Komodo didn't have to analyze any positions, it could just probe the tablebases and get its evaluation from them. But why didn't Houdini, Stockfish 11, and Stockfish 12 apparently do the same thing?

So, again, there is much about chess engines that I don't know. And, as they say, a little knowledge is a dangerous thing.

I had never heard of the "Rybka Randomizer" so I looked it up. I found some information here: http://rybkaforum.net/cgi-bin/rybka....

After reading and remembering that this "feature" was added to the Rybka Aquarium interface in about 2008 when the operation of chess engines was not as well known as it is today and when all (?) chess engines, including Rybka, were single-core.

The procedure is (mostly) independent of the engine used. It mostly consists of having two versions of the same engine play multiple games each other from a given starting position. This capability is provided by most modern chess GUIs, for example, Arena. I personally use it to simulate an MCTS-like search for the best move to play from a given starting position, just to get a different perspective than having an engine analyze a position using infinite analysis mode.. And, yes, you should use a fast time control (or a very short fixed amount of time per move) in order to get a sufficient number of game results that would make the conclusion statistically valid. This approach is similar to what's used in MCTS where in order to determine the best move a series of simulated games (playouts) are conducted using random moves to determine which move provides the best result from a given position in a statistically significant way.

You can also have two different engines (or more) engage in a tournament each other, with an even number of games and alternating colors so that White's first move advantage is neutralized. This is the same approach as is used in the TCEC superfinal, but there the objective is to determine which is the better engine so the 100 games are started from 50 different positions.

An advertised "big feature" of the Rybka Randomizer is the injection of randomness into the moves to be played. This might have been necessary or at least desirable in order to eliminate biases back in 2008 when single-core engines were deterministic. But today's multi-core engine are inherently non-deterministic so you get the desired randomization for free, so this "big feature" is no longer needed.

In AlphaZero vs Stockfish, 2018 <SChesshevsky> complained about SF's passive play while I defended it. Now it was my turn to be befuddled. LC0 fails to move its d-pawn until the game is completely lost. As a result it plays without its QB and QR. But looking at the game with the video and my desktop SF makes clear what a spectacular job SF does of hindering Black's development while promoting its own. The game really does wind up looking like Morphy vs. Amateur, though.

1.e4 e5 2.Nf3 Nc6 3.Bc4 Bc5 4.b4 Bxb4 5.c3 Ba5 6.d4 ed 7.0-0 dc (these are all preset moves; neither LC0 nor SF would play 7....dxc3 if it was up to them). 8.Qb3 Qf6 9.Bg5 (the "book" move here is 9.e5, but it isn't as if there's loads of precedent) Qg6 10.Nxc3 Bxc3 (this has been done, Janowski vs Lasker, 1901) 11.Qxc3 Nge7 (Lasker played 11...d6, which looks reasonable but can be strongly met with 12.e5) 12.Bxe7! Kxe7 (12....Nxe7 13.Ne5 and f7 caves in) 13.e5!

click for larger view

Hindering Black's development. If now 13....d6 14.Rfe1 White is winning. SF proceeds to show the advantages of space and development.

13....Re8 14.Rae1 Kf8 15.Bd3 Qh6 16.Re4! (threatening Rh4)

click for larger view

According to SF this was LC0's last chance to stay in the game with ....f5. Its main line, presented without comment, continues 17.ef Rxe4 18.Bxe4 Qxf6 19.Qc4 h6 20.h3 d5 21.Qxd5 Qe6 with a slight advantage for White.

16....g6 (another non-developing move) 17.Rfe1 Qg7 (trying to force ...d6) 18.Qc1 (if now 18...d6 19.ed Rxe4 20.Bxe4 is about + 6, so another non-developing move follows) 18....Kg8 19.h4! h6 (19....b6 trying to develop the bishop on the long diagonal and get the rook into the game is worth considering) 20.R1e3!

click for larger view

If I was playing Black I'd really be unhappy at this point. My desktop SF sees White as about +1.2 on a shallow search.

21.h5 g5 22.Nxg5! Apparently only here does LC0 realize how bad its position is.

click for larger view

...hg

If 22....Qxg5, the main line runs 23.Qc3 Re6 24.Rg3 Qe7 25.Reg4 Qf8 26.Bc4 +-; in other lines White can play Bb1 and Qd3. It's as if SF has all the time in the world.

23.h6! Qf8 (after ...Qxh6 24.Rh3, Black is left to contemplate the importance of moving its d-pawn). 24.Rg3! Nxe5 (LC0 does something! If instead 24....f5 25.ef Rxe4 26.Qxg5!! and, two pieces up, Black nevertheless has no defense against Qg7+) 25.Qxg5 f5 26.Rh4 Ng4

click for larger view

Note that LC0 is threatening ....Re1+ here -- its only threat in the entire game, I think. If instead 26....Re7 White can just go ahead and play Qg7+ anyway.

27.Rhxg4! fg 28.Re3!! (A rook down, SF nevertheless offers to trade rooks, because LC0 will be defenseless on the diagonals leading to the king. Of course, practically speaking SF isn't a rook down; it's a bishop up, because Black's QB and QR aren't participating in the game.)

28....Rxe3 29.Qxe3 d6 (a bit late) 30.Qd4+ Kg8 31.h7+ Kf7 32.h8/Q Qxh8 33.Qxh8

click for larger view

"Due to Chessbase?s repeated license violations, leading developers of Stockfish have terminated their GPL license with ChessBase permanently.

However, ChessBase is ignoring the fact that they no longer have the right to distribute Stockfish, modified or unmodified, as part of their products.

Thus, to enforce the consequences of the license termination, we have filed a lawsuit. "

The third judge, Lord Justice Birss, took a different view. While he agreed that "machines are not persons", he concluded that the law did not demand a person be named as the inventor at all.>

https://www.bbc.co.uk/news/technolo...

This moron ended up with "Chess for Android" (Aart Bik).

Why am I writing this? Because it was the only app that did not COMPLETELY freak me out at first sight. Tried them all (only google app stuff).

The standard GUI looks horrible (white is really white). But I found a pleasant setting (for the eyes):

<ChessBase GmbH and the Stockfish team reach an agreement and end their legal dispute>

https://stockfishchess.org/blog/202...

<The Ruy Lopez opening is generally considered to be better for White, as it allows White to control the center of the board and develop their pieces quickly. The Ruy Lopez is named after the Spanish bishop Ruy López de Segura, who wrote one of the first books on chess in the 16th century. In the Ruy Lopez opening, White starts by moving their king's pawn two squares forward, followed by the knight to f3, the bishop to c4, and the queen to d3. This formation allows White to control the center of the board and put pressure on Black's position.

Black has a few different options for how to respond to the Ruy Lopez opening. One common response is the Berlin Defense, in which Black moves their knight to c6 and their bishop to e7. This defense allows Black to protect their pawn on e5 and to create counterplay on the queenside. Another option for Black is the Marshall Defense, in which Black moves their knight to c6 and their bishop to d7. This defense allows Black to control the d5 square and to create counterplay on the kingside.

Overall, the Ruy Lopez opening is considered to be better for White, as it allows White to control the center of the board and to put pressure on Black's position. However, Black has a few different options for how to respond, and the game can still be very complex and challenging for both sides.>

Sounds authoritative, but as soon as it descends to specifics it starts spouting absolute nonsense (the bishop goes to c4??).

I also prompted it to compare "The Song of Achilles" and the Iliad. It knew that <TSOA> was a 2011 novel by Madeline Miller. But apart from that...among other things, it said that "The Song of Achilles" was narrated by Achilles (nope, Patroclus) and that gods and goddesses were largely absent (nope, Achilles' mother Thetis is all over the place).

It has a scary ability to sound like it knows what it is talking about while speaking absolute rot.

<In chess, if there are no other pieces on the board, how can a king and rook checkmate a king?>

<In chess, it is not possible for a king and a rook to checkmate a lone king. This is because, even when there are no other pieces on the board, a lone king is not in checkmate unless it is in check and unable to escape. In the situation you describe, the lone king would have the option of moving to any of the eight squares adjacent to its current position, which would allow it to escape from check and prevent the checkmate.

In order for a king and a rook to checkmate a lone king, they would need to have additional pieces on the board to block the king's escape. For example, if the king and rook were backed up by a bishop, they would be able to put the lone king in check and prevent it from escaping. The king and rook would then be able to move in a coordinated fashion to put the lone king in check from multiple directions, eventually trapping it in a corner of the board and forcing it into checkmate.

<I apologize if my previous response was not clear or accurate. In chess, it is possible for a king and rook to checkmate a lone king, but only under certain conditions. In order for a king and rook to checkmate a lone king, they must be positioned in such a way that the king is unable to move to any of the eight squares adjacent to its current position. This would mean that the king is in check and unable to escape, and the king and rook could then move in a coordinated fashion to put the king in check from multiple directions, eventually trapping it in a corner of the board and forcing it into checkmate.

However, it is important to note that this scenario is unlikely to occur in a real game of chess, as it would require the players to deliberately position their pieces in a way that would allow the checkmate to occur. In a typical game of chess, the players would be focused on developing their pieces and attacking their opponent's position, rather than setting up a situation in which a king and rook could checkmate a lone king. As a result, it is unlikely that this scenario would ever occur in a real game of chess.