|
< Earlier Kibitzing · PAGE 2 OF 2 ·
Later Kibitzing> |
| Jul-29-05 | | blackjacki2: I just have to play shredder a million times and I will finally win one |
|
| Jul-29-05 | | Autoreparaturwerkbau: <blackjack> Plus you have to play other 51 white's moves in the manner of Rating 2435 (as Lafuente's)! ;) |
|
Jul-29-05
 | | Sneaky: <My personal belief is that it was most likely a failure in the hardware, probably a memory (RAM) problem.> I'm more inclined to believe that they were correct with their statement that it was "a one in a million error in the hash tables." Hash-tables are faster than convential searching techniques, like B-trees, but you pay for that speed with accuracy. It's hypothetically possible to get a wrong answer from a hash-table. This can be corrected with methods involving "collision resolution" but for some purposes the cost of administration isn't worth the few rare times when it's actually needed. |
|
| Jul-31-05 | | The 3 Gambiteers: I'd like to have seen Lafuente's face after Shredder played 19...Rfd8??. |
|
| Aug-07-05 | | Caissanist: Sneaky, thanks for the elaboration, I didn't realize that "hash table" meant "hash table procedure" in this context. After re-reading the bulletin excerpt I now see that Shredder made exactly the same mistake when they gave it the position in the post mortem, which of course means you're almost certainly right. I'd still be curious to see if this same thing happened on a different hardware configuration, but it very likely would have. btw, according to the bulletin, LaFuente's "sorpresa fue mayuscala", a wonderful Spanish phrase that roughly translates as "his surprise was in all caps". LaFuente asked Shredder's operator if that really was the move, but under the rules he couldn't do anything but confirm that yes, indeed it was. |
|
| Dec-17-05 | | Knight13: <Rocafella: Even an idiot would have found Qxb7 so it must have been an error. Nevertheless it proves that computers are imperfect and are not incapable of error.> Yup. That's right. You can beat shredder. Sure you can. I can't wait to see that game... |
|
| Dec-17-05 | | aw1988: <Knight13> He's not saying he's better than Shredder, he's just saying that even computers make mistakes. |
|
| Dec-19-05 | | Knight13: <aw1988> Oh okay. Sorry for the misunderstanding... |
|
| Jan-25-06 | | RandomVisitor: This link:
http://www.seanet.com/~brucemo/topi...
Talks about "Zobrist Keys" and how they allow a hash table to work. In short, a 64-bit number is created from the pieces and their location on the board. This number is "usually" unique, and can be used to store an evaluation of a position. In this case, it appears that another position somehow had the same "Zobrist Key" and caused an erroneous evaluation to be retrieved from memory. |
|
| Jan-29-06 | | RandomVisitor: I decided to try and reproduce this amazing bug in Shredder 9.0. I entered the position before the 19...Rfd8 blunder, and after playing around with the hash table settings, here is what Shredder's display reads. Note that from 2 until 26 seconds into the analysis, Shredder thinks that Rfd8 is the best move. How humiliating. [Actual snippet from display:]
19...Qxb7 20.Nf3 Rfd8 21.Rxd6 Rxd6 22.Ne5 Ne4 23.Qc2 f6 24.f3 Ng5 25.Ng4 a5 26.bxa6 Qxa6 = (-0.07) Depth: 14/20 00:00:02 911kN
19...Rfd8
= (-0.08) Depth: 14/20 00:00:02 1344kN
19...Rfd8 20.Bc6
= (-0.08) Depth: 14/24 00:00:03 2095kN
19...Rfd8 20.Bc6
= (0.17) Depth: 15/26 00:00:04 2330kN
19...Rfd8 20.Bc6
² (0.67) Depth: 15/26 00:00:04 2417kN
19...Rfd8 20.Bc6 a6 21.Qc2
(3.81) Depth: 15/31 00:00:26 19137kN
19...Qxb7
(3.80) Depth: 15/31 00:00:26 19303kN
19...Qxb7
(3.45) Depth: 15/31 00:00:27 19375kN
19...Qxb7 20.Nf3 Rfd8 21.Rxd6 Rxd6 22.Ne5 a6 23.bxa6 Qxa6 24.f3 Nd7 25.Nxd7 Rxd7 26.Rb1 f6 27.e4 = (-0.04) Depth: 15/31 00:00:28 20505kN
19...Qxb7 20.Nf3 Rfd8 21.Rxd6 Rxd6 22.Ne5 a6 23.bxa6 Qxa6 24.f3 Nd7 25.Nxd7 Rxd7 26.Rb1 f6 27.e4 e5 = (-0.08) Depth: 16/23 00:00:30 21969kN |
|
| Feb-13-06 | | Achilles87: My 15 year old friend beat Shredder with the limit strength box unchecked.
Shredder can be beaten, perhaps even without it making glaring mistakes. |
|
| Jan-29-08 | | xrt999: <Caissanst says: btw, according to the bulletin, LaFuente's "sorpresa fue mayuscala", a wonderful Spanish phrase that roughly translates as "his surprise was in all caps". LaFuente asked Shredder's operator if that really was the move, but under the rules he couldn't do anything but confirm that yes, indeed it was.> If this is true, I would surmise that Fuentes was in shock for missing something! When the computer makes a move like that, 100% of the time it is a solid play, and you just blundered away the game. You dont just win a full piece! No, your piece is negligible in the attack beat down the computer is about to give you, a series of moves on the order of 10 or 11 forced moves deep. Everyone here knows what I am talking about. I would go on to further surmise that fuentes spent a good 10 minutes trying to see where he is about to lose. Just a guess. Furthermore, with 20.Bc6, I would say Fuentes showed this shock, because Shredder could have played 20...Rxc6 then win the c pawn. I really dont like this move. Still, even after 20...Ng4 I would say in the back of his mind for the next 4 or 5 moves, this nagging feeling was eating away at him that he was missing something. Just speculating. |
|
| Jun-17-20 | | Chesgambit: Strongest chess engine at 2005 |
|
| Feb-19-22 | | Cheapo by the Dozen: I presume Shredder was under the illusion that ... Rd8 won the knight that was pinned against the d1 rook. |
|
Feb-19-22
 | | An Englishman: Good Evening: Have never seen a glitch like this in a program of Shredder's strength. Can't imagine what sort of software bug bit; must be the computer equivalent of a Tarantula Hawk or Bulldog Ant. |
|
| Feb-19-22 | | Amarande: Back in the day, I had an older version of Shredder, and then later on a version of Junior. I don't remember Shredder doing anything spectacularly out there, but I DO remember Junior giving me an analysis line that included a move AFTER Black had been checkmated :) |
|
| Feb-19-22 | | goodevans: <Cheapo by the Dozen: I presume Shredder was under the illusion that ... Rd8 won the knight that was pinned against the d1 rook.> That's one possibility. Another is that it thought 19...Qxb7 somehow gave White an attack that was even worse and so 19...Rfd8 was just damage limitation. A third possibility is that a software bug ("undocumented feature") caused one or other of these moves to be wrongly evaluated. <RandomVisitor> postulated a theory about "Zobrist Keys" back in 2006 that sounds plausible. The link he gave no longer works but Wikipedia has this article: https://en.wikipedia.org/wiki/Zobri.... Note the bits about how "different board positions will <almost certainly> hash to different values" and "...<assuming> that hash collisions will not occur". |
|
Feb-19-22
 | | MissScarlett: <A Glitch in the Matrix
Are we in fact living in a simulation? This is the question postulated, wrestled with, and ultimately argued for in the latest provocation from acclaimed documentary stylist Rodney Ascher (Room 237, The Nightmare) through archival footage, compelling interviews with real people shrouded in digital avatars, and a collection of cases from some of our most iconoclastic figures in contemporary culture.> https://www.imdb.com/title/tt9847360/ |
|
Feb-19-22
 | | whiteshark: Tim Krabbe wrote about it:
"In July, Shredder, the strongest retail chess program, won a master tournament in Argentina with 8½ out of 10. It could have been even more. White had exchanged on b7, but Black didn't exchange with it and lost after 19...Tfd8 20.Lc6 etc. How can such a thing happen? The creator of Shredder, <Stefan Meyer-Kahlen>, didn't get it. <'It never does that,'> he wrote to me. It was assumed that something was wrong with Shredder's hash tables, tables in which evaluated theorems are stored. <Gian-Carlo Pascutto> of the program Deep Sjeng explained to me that <'hash collisions' can occur, where the computer extracts the wrong theorem from its table. But: 'The chances of this being caused by a hash collision are surely smaller than the chances of both of us winning the lotto every week for the next year, only to be wiped out by a comet hitting Earth.'> He thinks the error may have been caused by the hardware of a souped-up computer." https://timkr.home.xs4all.nl/admag/...
Translated with www.DeepL.com/Translator |
|
| Feb-19-22 | | spingo: This is interesting where someone says,
<whiteshark: <Tim Krabbe> wrote about it:
<"In July, Shredder, the strongest retail chess program, won a master tournament in Argentina with 8½ out of 10. It could have been even more.White had exchanged on b7, but Black didn't exchange with it and lost after 19...Tfd8 20.Lc6 etc. How can such a thing happen? The creator of Shredder, <Stefan Meyer-Kahlen>, didn't get it. <'It never does that,'> he wrote to me. It was assumed that something was wrong with Shredder's hash tables, tables in which evaluated theorems are stored. <Gian-Carlo Pascutto> of the program Deep Sjeng explained to me that <'hash collisions' can occur, where the computer extracts the wrong theorem from its table. But: 'The chances of this being caused by a hash collision are surely smaller than the chances of both of us winning the lotto every week for the next year, only to be wiped out by a comet hitting Earth.'> He thinks the error may have been caused by the hardware of a souped-up computer."> <chessgames.com: Shredder's only defeat from the 2005 Mercosur Cup was the result of an incomprehensible programming error.
<Lafuente has just captured a black bishop on b7, after which White must recapture. But Shredder plays the unaccountable 19...Rfd8?? The official bulletin says it was definitely not a mouse slip or any other kind of operator error, but that Shredder thought for over three minutes, initially analysing 19...Qxb7 to a depth of 20 ply but then switching to the move it ultimately played. The evaluation showed a slight advantage for Black. Only after the next move the value suddenly dropped to show a decisive advantage for White. Afterwards the organisers tested the critical position again with Shredder and diagnosed the problem as a "one in a million" error in the hash tables.>> |
|
| Feb-19-22 | | thegoldenband: <RandomVisitor: I decided to try and reproduce this amazing bug in Shredder 9.0. I entered the position before the 19...Rfd8 blunder, and after playing around with the hash table settings, here is what Shredder's display reads. Note that from 2 until 26 seconds into the analysis, Shredder thinks that Rfd8 is the best move. How humiliating.> This is fascinating! Seems like "smoking gun" evidence that it was indeed a hash table collision, or in any event NOT a hardware malfunction. Things with astronomical odds against them sometimes happen, <Gian-Carlo Pascutto>'s comments aside. |
|
Feb-19-22
 | | erniecohen: The odds of such a mistake are hardly "astronomical"; one in a million, as quoted in the original article, is not a bad estimate. If you search 20 million (~2^24) positions, each mapped randomly to one of 2^64 hash values, the chance of two positions mapping to the same hash is about 1 in 2^17, or about 1 in 128K. Moreover, most of these collisions don't matter much for various reasons (e.g. they are both bad, deep enough to be irrelevant, etc.). In short, this was not a programming error at all. It is a very standard programming technique, used in all kinds of software (not just games). The programmers knew of this risk and almost certainly calculated its probability. The judged (correctly) that the strength added by increasing search efficiency far outweighs the strength lost from rare hash collisions. |
|
Feb-19-22
| | erniecohen: The unintuitively high probability of a collision is sometimes called "the birthday paradox": if you choose 23 people randomly, the odds that two of them have the same birthday is greater than 1/2. |
|
| Feb-19-22 | | thegoldenband: Just to be clear, <erniecohen>, I wasn't claiming that the odds were "astronomical", but just paraphrasing <Gian-Carlo Pascutto>'s comments given above. (I see it as a reasonable paraphrase since, after all, he did mention a comet hitting Earth!) Pascutto is more qualified than I to assess the probabilities involved, so I could only guess he was engaging in hyperbole or somehow misunderstood the situation. Collisions in MD5 are famously trivial to find, and from your analysis this sounds similar. And yes, the birthday paradox came to my mind as well! |
|
Feb-20-22
| | erniecohen: <thegoldenband> MD5 hashes are 128 bits; the chance of hitting a collision in a 128-bit random function really is astronomical. Finding MD5 collisions depends on structural weaknesses in the hash function itself. It's far from trivial; it took mathematicians about 15 years to really break it. But for 64-bit hashes, it's easy to find collisions by brute force, even if the hash function itself is perfectly random. |
|
 |
|
< Earlier Kibitzing · PAGE 2 OF 2 ·
Later Kibitzing> |
Kibitzing
