|May-04-04|| ||Wild Bard: What the heck happened, did Chaos decide to rub his silicon brother's nose in it???? |
|Jul-23-04|| ||Dick Brain: That was a peculiar finish. A little bug in the mop-up algorithm I suppose. |
|Jul-23-04|| ||suenteus po 147: I love the phrase "mop-up algorithm!" |
|Oct-25-04|| ||Knight13: The finish is very strange. Chaos could have checkmated Chess 4 earlier in the endgame. |
|Oct-26-04|| ||poktirity: Maybe it wasn't able to calclulate far enough to se the checkmate :) |
|Nov-05-04|| ||WMD: 16.Nxe6 is said to have been the first positional sacrifice played by a computer in a serious game. |
|May-13-05|| ||Caissanist: LOL, figuring out the how to handle passed pawns was definitely the hardest thing for the programmers to get right. This is from the days when computer chess was always good for a few laughs.|
|Jun-14-06|| ||mack: <16.Nxe6 is said to have been the first positional sacrifice played by a computer in a serious game.>|
From the Batsford Chess Yearbook 1974:
16.Nxe6!! If a human being had played this move it would merit at most one exclamation mark. However, it was played by a computer which was allowed to calculate only two moves in advance; thus the sacrifice, a real one according to Spielmann, was made on positional grounds. This is the first known example of such a sacrifice by a computer.
|Jun-14-06|| ||Gypsy: <16.Nxe6!! ... it was played by a computer which was allowed to calculate only two moves in advance;...> So, 18...Bd8 was beyond the computing horizon?|
|Jul-08-07|| ||RandomVisitor: The same moves were played in the correspondence game Montanella-Burigana 1970 (source: chesslab.com), including the famous Knight sacrifice. |
The famous knight sacrifice (16.Nxe6) could in fact have come from the CHAOS opening book.
|Sep-19-07|| ||argishti: 16.Nxe6!! wow, this shows how computers even in the 70's can make such gorgeous positional sacrifices! although, i cant make sense out of the weird long ending...|
|Sep-19-07|| ||pawnofdoom: Wow! Great game by computers 30 yearso ago. I didn't know they could be this good. But it did take it quite a long time to checkmate, as instead of going for a simple kingand rook vs king checkmate, Chaos played on another 30+ moves to promote a queen and then checkmate that way|
|Feb-03-08|| ||staplerman: Can someone tell me why Chaos moved its rook up and down the b-file so much?|
|Feb-03-08|| ||Ed Trice: <staplerman> You have to remember, it's 1974. I think this is the year hash table performance was "just invented" by the Northwestern University team. So, there's a strong chance the transpositions were not even being hashed, and the program had to search all nodes as if they were "new." |
If you look at where the pawns were, they were 2 moves from promotion when all the rook shuffling is going on. That's 4 plies to see the crowning, but the lone king could "reach the Rook" and "capture it", producing a score change of -5.0 pawns.
This, no doubt, caused a "research", and would be very disturbing to a shallow search.
I don't think the hardware was capable of searching 6 plies in this position, so any move that could delay promotion by one move would appear to "save the day."
|Jun-08-11|| ||kia0708: one of the funniest end games ever !
|Jun-15-11|| ||Caissanist: No way did Chaos play the 16th move from an opening back. In 1974 no computer went that deep in its opening book, there simply wasn't the storage capacity. The most powerful computer in the world then had less storage capacity then you can get today on a USB flash memory stick for $10.|
|Jun-15-11|| ||Caissanist: Looking over the ending again, and thinking back to my own days as a FORTRAN programmer, I can guess what happened. The people who wrote Chaos just wanted to have a simple algorithm for handling easily won endings that always worked. And they did--no matter what the opponent does, their technique (using the word very loosely) of keeping the rook away from the enemy king and cutting off files will win. It's not elegant or optimal, but it minimizes the quantity of code they had to write and the likelihood of bugs creeping in. It's also not that different from how many of us play bullet games when we only have a few seconds left to cash in a winning position. |
Btw, this doesn't necessarily conflict with what Ed Trice wrote, which is very likely how you might implement a program following these design principles.