Probably, certainly the good ones. And I wonder if Doroshenko was aware of "my" game. :-)

What I thought was interesting was that, in spite of the materialistic opinion that many have of computers, that a computer played a strictly positional pawn sac whose evaluation, material-wise, could not be foreseen since Stockfish could not calculate far enough ahead to determine if it would ever win the pawn back.

<My stance is still the same. You learn more from human blunders than pure computer analysis which knows nothing of the background.>

And my stand is still the same also. Human blunders (unless they're <my> blunders) are interesting but to me nothing more. And the game's background, while often informative in determining why the human blundered in the first place, are not interesting to me from the perspective of determine what is <objectively> the best move in any position. So here, again, we'll just have to agree to disagree. We simply have different priorities in this area.

<Showing 20+ moves of what a computer considers best play in a human v human game is a waste of space. One human move and it's wasted.>

I certainly agree with the second sentence. Then again you can say the same thing about a detailed analysis during the game if one is not sufficiently alert to abandon one's concurrent analyses and plans in order to take immediate advantage of a blunder by one's opponent. That used to be (and still is) a major failing of mine. I was so mentally and inflexibly committed to my plan that I would not recognize unanticipated opportunities presented to end the game much quicker. Which would typically happen in almost any game, certainly at my level of play. None of that "If you see a good move, look for a better one." for me. Unfortunately.

<Look how the human v human game I linked too finished E Hansen vs M Doroshenko, 2013 finished. White a GM plays a move no computer could ever predict.>

"So here, again, we'll just have to agree to disagree. We simply have different priorities in this area."

We disagree on a few minor things but nothing too serious. We have been having this discussion for nearly three years now and not once have either of us resorted to name calling.

Having differences is normal and even beneficial, they force you (or should force you) to re-inspect your beliefs and maybe even change them due to the new information that you find. And I think that's a good thing. Besides, it would certainly be boring if two people always agreed on everything. What would they have left to discuss, chess?

They (that will be you and your boffin pals ) are solving chess backwards with Table Bases.

How long before we get the 32 bit Table Base? (Last time I checked - a pun! - it was up to 8 bits.)

Table bases and chess computers are mildy interesting.

Let us assume a computer with has only access to a 6 bit Table Base, would they do this. (White to play)

click for larger view

It knows it is winning but the mate is beyond it's horizon - however it can dip into it's 6 bit T.B. and see if it plays 1.d7+ Kxd7

click for larger view

That's position according to it's 6 bit T.B. is mate in 20 which it can show within a nanosecond and need not calculate anymore. It can play and reply instantly.

In this case the answer is "maybe".

click for larger view

But first let me digress and discuss how chess engines use tablebases. The engine does not need to wait until the position on the board (currently) has 6 pieces or less. Engines look at several, but typically not all, possible moves from a given position and create a tree of possible lines. In this case White has 9 legal moves, 3 pawn moves and 6 king moves, so it would likely consider the continuation 1.d7+ Kxd7. Now the number of pieces in this position in its search tree is 6 so it can look up the result in its tablebase and find out that White has a forced mate. And, if this was an actual game it probably would have detected the forced mate several moves prior to reaching the position above.

The reason I say "maybe" is that <all> legal moves by White in this position result in a forced mate, and it none of them are beyond its horizon within 1 minute of calculation. But the Syzygy tablebases that most engines use do not have so-called distance to mate (DTM) information so all the engine knows is that a particular line will lead to a forced win but it doesn't know how many moves will be required. And the engine evaluations based on Syzygy tablebase information are artificial and engine dependent; they will typically be a number higher than [+128.00] + other engine-specific information. So, it will either select the move with the highest (artificial) evaluation or, if two or more moves have the same (artificial) evaluation, it will select the first move that it finds in its search tree that the tablebases say is a forced win and consider that the "best" move.

In this case I had Stockfish 9 analyze the position above and the first move it found that let to a forced win was 1.d7+ with an evaluation of [+132.75], d=10 which it found in less than 1 second. At d=11 it found that 1.Kf4 with an evaluation of [+132.74] would also lead to a forced win but because its evaluation was one centipawn less than 1.d7+'s, it selected 1.Kf4 as the second "best" move.

By d=12 it had found that all legal moves except 1.f5 let to a forced win and it listed them in descending evaluation order with those moves that had the same artificial evaluation listed in the order that it found them in its search tree. And by d=13 it had found that 1.f5 also lead to a win and its [+132.74] evaluation was the same as the evaluation for 1.Kf4 and 1.e5, so it promoted 1.f5 as the fourth "best" move (because it had found the other 3 moves first) over the other 5 moves.

This situation remained the same until d=32 with only minor changes in the move evaluations. But at d=33 it's normal evaluation function uncovered a forced mate in 17 moves, [+M17], for 1.e5 and so it promoted it to "best" move above all the other moves that only had artificial evaluations based on the information from the Syzygy tablebases. At d=37 it modified its expectation of 1.e5 and increased its evaluation to [+M16] (one less move required for mate) and found a forced mate in 18 moves for 1.Kh4. So these two moves now became the 2 best moves, with the preference given to 1.e5 since it led to a forced mate in 2 less moves.

At d=41 (coincidentally requiring 41 seconds) Stockfish's normal evaluation function found forced mates for all 9 legal moves with the minimum number of moves required being 16 for 1.e5 and the maximum number of moves required being 22 for, yup, 1.d7+. So, per Stockfish, 1.d7+ is the <worst> move for White to play in this position since it required the greatest number of moves to force a mate.

So whether Stockfish 9 would have played 1.d7+ would have depended on the search depth that the analysis was carried to:

(a) if d<19 (<1 sec) it would have played 1.d7+ because it had the highest, though artificial, evaluation.

(b) From d=20 (<1 sec)through d=26 (1 sec) if would have played 1.d7+ because it had one of the highest evaluations and it appeared first in Stockfish's search tree.

(c) From d=27 (1 sec) through d=32 (4 secs) it would have played 1.d+ because once again it had the highest evaluation.

(d) For d>33 it would have played 1.e5 because it found that it resulted in a forced mate in the least number of moves. In fact, 1.d7+ would have been the <last> move that it would have played since it required the greatest number of moves to force mate.

Thanks.

I did not make it clear that the computer I had in mind would have been a bit weaker than the modern monsters.

Let us say looking just 4 ply ahead so it cannot see any distant mate.

Would it first look to sac that d6 pawn so it could access it's 6 bit T.B. to have a peek so to speak.

Sorry about that. But, if you're not using the latest technology, what's the point of trying to see how older technologies might have handled the situation?

I was thinking far ahead to the days of a 12 bit T.B. then the position would far too deep for a computer to see a distant mate.

If the weaker models peeked into the T.B's. would one of today's much stronger models also do the same and perhaps chuck a piece or pawn just to access it's T.B.

---

I use to sell these old models up till 1992. I know all about their limitations.

In the very very early days, we are talking about the ZX81's, they would spot this mate.

click for larger view

but not this one...

click for larger view

Firstly, about Fischer vs Geller, 1967.

There, at Fischer vs Geller, 1967 (kibitz #410) I said this:

<offramp: Writing with 15 years of hindsight, Geller thought he would have lost.

<This loses in paradoxical fashion. As Fischer writes, a couple of hours after the game he found the problem-like win 20 Qf4!!, with the threat of 21 Rh5. <Black has no way of equalizing>, for example, 20.cxb2 21 Rh5!, and now ....>

Here Geller gives various interesting variations and then summarizes:

<This is the truth, established after many years of painstaking analysis. The number of moves with two exclamation marks demanded of White shows how difficult it was to find all this during the restricted time of one game. A calculation of all the variations was impossible, and intuition in sharp situations was not Fischer's strongest weapon.>

From <The Application of Chess Theory>. ~1983>

& I added, and this is important:

<I'd simply say that if Geller thought 20.Qf4 would have won 15 years later, then it would've won on the day.>.

The position is in fact drawn.
*****
Karpov vs Kasparov, 1984

click for larger view

This position is a draw.
Annotating the game much later, both Kasparov and Karpov thought that White would have won with 28. Qc4.

I don't understand what you mean by "on the day". If "on the day" you mean what actually happened on the day when the game was played (the only result that really matters), then that would be 0-1 in Fischer vs Geller, 1967 and 1/2-1/2 in Karpov vs Kasparov, 1984.

If by "on the day" you mean the day when a particular analysis was done, then that would be whatever the analyst thought on that day, whether right or wrong.

And I know that Geller thought that after 20.Qf4 he would have lost, but that doesn't mean that Geller was right "on that day". As you know, I did extensive chess engine analysis of the position after 20.Qf4 and I couldn't definitely conclude that White would have won after 20.Qf4. So I would then say that "on that day" the result was unclear. And if someone arrives at a different conclusion at some time in the future, then "on that day" the result would be whatever that person said.

And today in your post you first say that for Fischer vs Geller, 1967 "The position is in fact drawn" and at the end of the same post you say "The only possible answer, I think, is a win for White in both games." So I'm really confused as to what you mean by "on that day"

I can't see why a computer would chuck a piece or a pawn just to access its tablebase. Instead it might consider chucking a piece or a pawn as it searches deeper and deeper from the position that it is currently analyzing and then, if after that chuck it reaches it's tablebase piece threshold, then it could look up the outcome of the sac. So it would know well before the chuck was actually played whether it was a "good" chuck or just an upchuck.

Sorry again. In the diagram positions the ZX91 was black and it is a bare bones position - there will be other bits on the board.

It spots the mate threat because the h7 pawn is attacked so defends the pawn, not the mate.

With the pawn on h5 the pawn is not attacked not is not being attacked so the ZX81 gets mated.

---

"I can't see why a computer would chuck a piece or a pawn just to access its tablebase"

I was wondering how the program ran - would it peek into it's TB with there being only one piece more on the board before it can use it's TB.

After all a TB is a potent weapon, once accessed all debates about horizon's and minor glitches are out the window.

To a certain extent I and other humans do. We call it simplication if it is a more complex position but still won it would be technique.

Here is a very crude example of simplication.

click for larger view

TECH simply evaluated all legal moves to a fixed depth and then it evaluated the terminal positions only with respect to material. So if the chess program in the ZX81 (presumably https://en.wikipedia.org/wiki/1K_ZX... but you would know better) worked similarly then it would give precedence to 1...h5 since it would then not lose a pawn as compared to other moves which also didn't lose a pawn or worse. That would mean that with all the additional pieces on the board that there must not have been any other moves that would also lose material.

But that also wouldn't make all that much sense since allowing 2.Qxh7# would certainly lose material; i.e. the king. So there must also have been a flaw in 1K ZX Chess that somehow did not correctly evaluate the "material" value of checkmate. Talk about a defenseless king!

And I think that my suspicion might be right. In http://users.ox.ac.uk/~uzdm0006/sca... the author describes how !K ZX Chess works, and it has the following description of the PSC evaluation function:

"PSC gives a score to a chess piece Q(5), R(4), B(3), N(2), P(1)." No value provided for the king!!!

As I've often said, "The things you learn by visiting <chessgames.com>" (plus some on-line searching, of course)

One last puzzling thing. According to some of the on-line information (https://en.wikipedia.org/wiki/1K_ZX..., https://chessprogramming.wikispaces...) 1K ZX Chess (also dubbed http://thad.frogley.info/archive/th...) only had 672 bytes of memory available for the entire program, could only start with 1.e4 or 1.d4 and did not implement castling, promotion, or en passant captures. So did you get your starting position with the Black rook on f8 and the Black king on g8? Perhaps your memory of the program's capability was also limited. :-)

BTW, I found the description of 1K ZX Chess so interesting but so difficult to read that I took the time to clear it up. You can download my cleaner description from http://www.mediafire.com/file/e3h8n.... Who knows, you might find it "mildly interesting". :-)

<I was wondering how the program ran - would it peek into it's TB with there being only one piece more on the board before it can use it's TB.>

" So did you get your starting position with the Black rook on f8 and the Black king on g8?"

As I said I just made the position up. Later ZX81 versions (you needed a 16K add on chunk of plastic to increase the memory) certainly did castle but suffered from the same flaw. Material first - the critical square 2nd.

Bill Hartston mentions an early computer that was told the King must control the central squares.

So in the opening it's King would head towards the centre and get mated fairly quickly.

They modified it saying only control the centre in an ending.

Consequently it could not mate with White from here.

click for larger view

(again not the exact position) because it was told a King had to control central squares and bringing the King over to the c-file went against it's programing.

Sorry to wake you up so early.

You have all the supper-duper stuff. This position. White to play.

click for larger view

How long before your collection of computers declare it a draw.

I used it recently in a post where I display my new pop-up chess book.

https://www.redhotpawn.com/chess-bl...

And the solution?

Ha! You should know better than to show an old player a famous position from an old book. It is, of course, from Hans Kmoch's classic "Pawn Power in Chess" in the chapter "The Sealer and the Sweeper".

click for larger view

So I don't need to ask no stinking computers to know that 1.Ba4+ draws after 1...Kxa4 2.b3+ Kb5 3.c4+ Kc6 4.d5+ Kd7 5.e5+ Kxd8 6.f5

click for larger view

And a draw after no more than 50 moves since there are no possible pawn moves or piece captures. Kmoch also pointed out that several of White's k-side pawns could be replaced with pieces, e.g. Bf5 (but I don't see how with 8 pawns on the board, White could have had 3 bishops), Ng4, and Nh3 with the same effect as long as White does not succumb to the temptation to move them.

And, for a change, in this case I was ahead of you. Back in 2011 (Team White vs Team Black, 2011 (kibitz #1051), Akobian vs The World, 2011 (kibitz #3513)) I had 13 (!) engines analyze the initial position and not one of them even came close to finding the draw, even after I started the analyses from the position following 1.Ba4+. In fact, none of them allowed 5...Kxd8, preferring to instead move the bishop to reduce White's material deficit.

But that was almost 8 years ago and that's an eternity in terms of computer hardware and chess engines. So tonight I will have Stockfish 9 (it searches the deepest) analyze the position overnight and see if it can find the draw.

I'm also curious to try my recently purchased Komodo 12 with the MCTS option. This option uses a Monte Carlo Tree Search (MCTS) supposedly similar to the one that AlphaZero uses and instead of the usual search tree expansion with alpha-beta pruning and hand-crafted evaluation functions, it runs multiple simulations at every position and determines the win, draw, and lose probabilities. It then select the move to be played as the one with the best scoring percentage. Since the game simulations are run until a game result is obtained, presumably this overcomes any adverse horizon effect.

This is a quote from the Komodo 12 ReadMe file concerning the MCTS option that I think you would approve of, at least if it is true:

"MCTS is different from traditional chess engine search techniques in that the search is guided by win probabilities instead of a traditional alpha-beta search and evaluation. The result is a more human-like way of playing, since humans, like MCTS, are normally concerned with what move will give them the best chance to win (or draw if in inferior position) against an imperfect opponent, not what move is best against perfect play, which is what alpha-beta search tries to do. MCTS often gives very different move choices than normal Komodo."

Well, I unfortunately don't have a super-duper machine. My computer is about 8 years old and only 32-bits so it's fairly slow for today's technology. But my chess software is up to date. And (I think) that I know how to use it.

So here's what I did. I had Stockfish 9 (latest released version) analyze this position using 4 cores and a 1024 MB hash table:

click for larger view

I let it run overnight and beyond (a little over 12 hours) and it got to search depth (d) = 38. I let it display its top 3 moves at each search ply.

Did it declare it a draw? Well, no, but I think that it can get partial credit, but you be the judge:

1. It found 1.Ba4+ as its 3rd best move with an evaluation of [-10.16] (definitely losing) at d=19 in only 00:00:11. But it only got as far as 1...Kxa4 2.b3+ Kb5 3.c4+ Kc6 when it chose 4.exf6.

2. It then dropped out of Stockfish's 3-move display threshold until d=22 after 00:00:42 when Stockfish considered it it's 2nd best move with an evaluation of [-10.59]. But it still chose 4.exf6 after the first 3 moves of the drawing line. But from this point forward Stockfish considered 1.Ba4 as it's 2nd best move 12 times out of the next 15 search iterations and once it considered it its 3rd best move.

3. From here on it gradually converged and found the drawing line:

a. It found 4.d5+ at d=27 after 00:04:20 but considered 5.Bxa5 to be best.

b. It found 5.e6+ Kxd8 6.f5 at d=35 after 02:41:34, thus completing the drawn position:

click for larger view

But it didn't <recognize> that it was a drawn position. For it to do that it would have had to reach at least d=56 (the first 6 moves + 50 moves without a pawn move or piece capture). I checked the Stockfish 9 code and it did include a 50-move counter so it would/should have detected a draw then.

And, unfortunately, as long as Stockfish considered 1.c4+ as its best move, that's the move it would have played.

But how long would it have taken Stockfish 9 on my system to reach d=56 and presumably recognize that the position is a draw? The time to advance one ply increases exponentially, so I graphed the data I had using Excel and added a trendline. Excel would not let me use an exponential timeline but I got fairly good agreement using a 5th degree polynomial (R2 = 0.9871) so, given that it's an extrapolation, probably good enough. It projects that it would have taken Stockfish 9 slightly under 1,000 hours or about 41 days. Needless to say, I'm not going to wait that long.

However, if I were to use a 6th degree polynomial I would get a better agreement (R2=0.993) but it would then project that it would have taken Stockfish 9 slightly less than 2,300 hours or 95 days. Then again, extrapolation with higher degree polynomials is notoriously inaccurate, so take these estimates with a grain of salt. However, a "long time" would not be an inaccurate estimate.

1. Komodo 12 MCTS found 1.Ba4+ in both analysis runs as early as search ply (d) = 19 after only 6 seconds of calculation, and in both runs it considered 1.Ba4+ to be White's best move. But in both runs it continued with 1...Kxa4 2.exf6 and it never played 3.be3 in either run. So I would say that Komodo 12 MCTS never found the drawing line, and might never do so even if it reaches search depths > 35 (see below) regardless of how long you let it run. And, from what I've recently re-read about MCTS that might not be an unusual result since, according to https://en.wikipedia.org/wiki/Monte..., a disadvantage of MCTS is that "faced in a game with an expert player, there may be a single branch which leads to a loss. Because this is not easily found at random, the search may not "see" it and will not take it into account." This would apply in this case since there is only one line, 1.Ba4+, that avoids a likely loss, as far as these 2 engines are concerned, with evaluations of [-15.36] by Stockfish 9 (d=38) and about [-4.00] by Komodo MCTS (d=35).

2. I ran both analyses for over 8 hours but Komodo MCTS never got beyond d=35 after 01:26:20 and 01:46:15 respectively. That's why I did the second analysis, to see if I made a mistake in the first one. I don't know if I set it up incorrectly but maybe, since this version is somewhat experimental, there is a bug in the program, at least in the 32-bit version that I'm forced to use. I'll contact the Komodo developers and send them my data to see if they find out anything that I did wrong. After all, they indicated in their Komodo 12 documentation that "The MCTS is experimental and in its infancy."

3. While the time to reach a given depth also increases exponentially, Komodo MCTS was almost twice as fast as Stockfish 9 in reaching d=35; it took Stockfish 02:41:34 to reach d=35. This was a surprise to me since, of the top engines, Stockfish gets to a given depth much faster than any other engine. But the "search depth" in MCTS is not quite the same as the search depth in engines using alpha-beta pruning (ABP) so, as the Komodo 12 documentation also says, "MCTS is not like a traditional search where depth is increasing and reported as a new iteration is completed. Instead, best move choices are updated once every 3 seconds, so it can appear some depths are skipped over. Since most GUIs want to see a depth output, Komodo estimates the depth based on MCTS nodes searched". So the search depth numbers are not exactly comparable between Komodo MCTS and Stockfish.

4. The results I got in both runs were different in regard to what Komodo MCTS considered the top 3 moves to be as well as move rankings and move evaluations. So it seems that, using multi-core engines, Komodo 12 MCTS is just as non-deterministic as engines using ABP, including Komodo 12 "normal". The non-determinism of chess engines using ABP is well known but I've never seen any mention of non-determinism with chess engines using MCTS. So this might be the first observation. It remains to be seen if using only one thread/core eliminates the non-determinism in Komodo 12 MCTS as it does with Komodo 12 "normal". Who knows, using a single thread might allow Komodo 12 MCTS to reach search depths > 35.

With respect to <morfishine>'s good observation that after 1.Ba4+, 1...Kc4 also allows a draw by repetition, he's quite right. I suppose that if the study was labeled "White to play and draw" then Kmoch's composition is technically correct, but I would still consider it a minor flaw in terms of the uniqueness of the solution and demonstrating the "Sealer and the Sweeper" concept.

However, if you place the White king on d3 instead of d2:

click for larger view