BBO Discussion Forums: 0% plays, part 2 - the most remarkable GIB bug you'll ever see - BBO Discussion Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

0% plays, part 2 - the most remarkable GIB bug you'll ever see

#1 User is online   smerriman 

  • PipPipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 3,777
  • Joined: 2014-March-15
  • Gender:Male

Posted 2022-August-08, 03:34

In an earlier post I debugged my way through a hand where robots made a 0% play on defense. The cause was the surprising failure to calculate double dummy scores accurately.

Today I remembered I had seen one other 0% play reported on BridgeWinners - this time by an advanced robot declarer.

Here was the original hand as posted:



After 10 tricks, you have a trivial cross-ruff to take the remaining 3 with high trumps. Instead, GIB plays a trump, which guarantees the contract going down on any lie of the cards.

Not as much debugging output is available for declarer play in the 10-year-old command line version of GIB, so I didn't expect to make much headway with this one. You don't get to see any of the hands that are being simulated, and GIBson's single dummy algorithm is more complicated to understand. However, you do get some insights, such as what opponent's holdings GIB is "playing for" and how many tricks it expects to take for that holding.

After 7 tricks, GIB correctly calculates that the contract has no hope of making with accurate defense, with 9 tricks the limit.

But when human North errs by ruffing with the Ace, GIB.. *still* thinks the limit is 9 tricks, and continues down the path it calculated to its desired goal of 9 tricks.

Now, you're probably thinking - this doesn't sound remarkable. Just some weird glitch where it can't see a winning line has arisen.

There's more.

While debugging this in the command line GIB, I was messing around with going back and forward a trick or two and trying different options to see if it would ever come up with the winning line. So I'd undo a few moves, try something else and so on. And I found something strange - after GIB concedes the contract with the trump lead at trick 11, I undid a trick and repeated it - and it discovered the diamond play for 10 tricks.

If I undo back to the point before North erred, and then go back forward.. it can only find 9 tricks.

And most importantly - this is replicable today in a teaching table on BBO. Predeal the above hand, put an advanced robot in West, and play through the hand matching the cards above from the other three seats. It will throw the contract at trick 11. Hit undo once.. and it'll suddenly be able to make the contract. Hit undo again once.. and it'll still play the diamond. No matter how many times you try this (clicking undo once only each time), it'll find the winning line every single time, so it's not randomly switching between them.

But hit undo several times in quick succession to get back to before North plays the Ace, then play forward again - and it'll be back to the guaranteed failing line.

GIB is clearly using cached information that it shouldn't be. If a simple undo is enough to clear the cache properly, then this is trivial to fix.
3

#2 User is offline   cherdano 

  • 5555
  • PipPipPipPipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 9,516
  • Joined: 2003-September-04
  • Gender:Male

Posted 2022-August-08, 15:35

I used to help improving GNU Go, and through that was also a little bit familiar with a number of other go programs (interfaces, clients for go servers, etc.). There was not a single program that didn't at some point have a bug in handling undos.

So it's amusing to me to see an example where an undo fixes a bug!
The easiest way to count losers is to line up the people who talk about loser count, and count them. -Kieran Dyke
0

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users