BBO Discussion Forums: GIB makes DD error?? - BBO Discussion Forums

Jump to content

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

GIB makes DD error??

#1 User is offline   gwnn 

  • Csaba the Hutt
  • PipPipPipPipPipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 13,027
  • Joined: 2006-June-16
  • Gender:Male
  • Location:Göttingen, Germany
  • Interests:bye

Posted 2020-December-05, 08:26

I've never seen this ever:

https://tinyurl.com/y5mmmjr3

The first 7 tricks and the first card to Trick 8 are entered. If you ask the DD analyser what East can play and still beat the contract, the 10 and the 8 are both "red" (ie good enough for down 1). But if you play the 8 and ask GIB again, the contract is makeable assuming South plays low (and this is obviously the correct analysis).
... and I can prove it with my usual, flawless logic.
      George Carlin
1

#2 User is offline   nullve 

  • PipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 2,228
  • Joined: 2014-April-08
  • Gender:Male
  • Location:Norway
  • Interests:partscores

Posted 2020-December-05, 10:13

GiB's analysis was correct (red T, green 8) when I played through this at a teaching table.

But if I try to document this here (using Export -> Handviewer link etc.):



:(
0

#3 User is offline   smerriman 

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

Posted 2020-December-05, 13:10

Interesting. It doesn't appear to be an error with the double dummy part - the response from that is correct:

Posted Image

So it must be an error at a later stage of the handviewer code.
1

#4 User is offline   smerriman 

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

Posted 2020-December-05, 18:11

The handviewer JS is pretty obfuscated but that doesn't stop someone like me from debugging it :)

When the double dummy solver is called, it only considers "highest of equals" so that it can perform as few double dummy calculations as possible. Eg when your suit is AQJ54, it will calculate the double dummy result for playing the A, Q, or 5. It also eliminates cards from past tricks from calculations, so if the king had been played in a past trick, it will then only look up the result of playing the A, or the 5.

The handviewer code then loops through each result, and figures out all of the "equals" that result applies to. It starts from the card returned (eg Q), adds the result, then goes down one card at a time - J, T, 9.

If it finds that card in your hand, it applies the same result and continues down.
If if finds that card in an earlier played trick, it skips it and continues down.
If if finds that card in someone else's hand, or it has been played as part of the current trick in progress, it stops.

However, the loop that goes through the "current trick" has an off-by-one error - a < when there should be a <= . This means the most recently played card to the trick (in your example, the 9 of diamonds) is considered to be entirely missing from the deal in terms of "equals". It therefore continues down and thinks the 8 is equal to the ten, so applies the same score to the 8.

On the double dummy solver's side, the same bug does not appear to exist - it is returning a result for the T, and a separate result for the 8, not considering them equals. Therefore, in most circumstances, the bug in the handviewer automatically "fixes" itself - it starts with the T, which results in the wrong score assigned to the 8, but then continues onto the next double dummy result that was returned (the 8) and overwrites it with the correct value.

However, in this case, the results are being returned in increasing order of pips - so it's applying the result to the 8, then continuing onto the T which overwrites the correct result for the 8.

Changing < to <= in the appropriate loop fixes everything.

I tried setting up some example hands to make the bug even clearer. But when I tried this hand on the lead of the king of diamonds:



everything works as intended - it turns out the double dummy results returned have the Ace listed before the Queen, so while it does incorrectly assign results the first time through the loop, it fixes itself the second, so you never know anything went wrong.

This intrigued me further - what causes results to be returned in increasing order sometimes, and decreasing others? I played around with more hands and was fascinated to find it was something to do with signalling. That is, if you look at the double dummy results for an opening lead, the results for 4th high from a suit etc are listed before other cards. So perhaps this is the inner "bonus" GIB is meant to give certain cards when determining which one to play.

Fun stuff all round, but now trivial for BBO to fix :) (It's in the gibDataReceived function - the last else condition, where it loops up to < inTrick, but inTrick appears to be 0-indexed, so should be <=).

@BBO - is this a good time to repeat my numerous requests to see GIB's code :( Even if I can't fix anything like here, not being able to do the above and see *why* GIB does things drives me insane.
7

#5 User is offline   bavard25 

  • Pip
  • Group: Members
  • Posts: 1
  • Joined: 2021-September-08

Posted 2021-September-08, 14:51

Very interesting! I found a DD error too and Google led me here on my search for answers. My case is equivalent to the ones already presented, so I guess it still hasn't been fixed.
0

#6 User is offline   Stefan_O 

  • PipPipPipPip
  • Group: Full Members
  • Posts: 469
  • Joined: 2016-April-01

Posted 2021-September-11, 16:53

View Postbavard25, on 2021-September-08, 14:51, said:

Very interesting! I found a DD error too and Google led me here on my search for answers. My case is equivalent to the ones already presented, so I guess it still hasn't been fixed.


Hi Bavard.

Woiuld you care to post a link to your deal too, where the DD analysis is still wrong?
0

#7 User is offline   yadny 

  • Pip
  • Group: Members
  • Posts: 4
  • Joined: 2015-March-17
  • Gender:Not Telling

Posted 2021-December-14, 04:24

here's one:

https://tinyurl.com/y8ac45v9

At trick 8, when East leads a trump, the double dummy analysis indicates that South can play any trump and still make 12 tricks; however, in order to make 12 tricks it is necessary to play the Jack (you retain the ability to win the trick in either hand, depending on West's discard)

this can be verified by pressing 'play' and making South play the 9 or the 7, then checking the DD analysis on West's play
0

#8 User is offline   smerriman 

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

Posted 2021-December-14, 13:41

lol, really BBO? All you had to do was change a *single character* in the javascript file.. and that one-character bug is still there. Somehow the developers must have done something else as a workaround for the first hand, without resolving the actual problem. The one-character change still perfectly resolves the last diagram. Now to figure out what they *actually* changed and whether that has unexpected consequences..
0

#9 User is offline   smerriman 

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

Posted 2021-December-14, 14:04

Yep, BBO tried a different fix that doesn't work at all.

Their change: if a +/-/= box has already been added to the card, then don't overwrite it with another one.

This works in the original example since the order returned by the DD analysis is 8, T, A. So after it calculates the results for the 8 (=), it doesn't overwrite it when working on the T like it used to.

But in the most recent example, the order returned by the DD analysis is J, 9, 7. It calculates the results for the diamond J, thinks the diamond ten doesn't exist due to the off-by-one bug, and applies the same score to the 9. Now when it comes to the 9 loop, it has the correct value but the new code logic tells it not to override it with the right one.

In fact, take another look at my post above where I posted this sample hand that I expected to be broken before, but was working:



Lead the king of diamonds and press the GIB button to see the exact example I provided is now broken in a hilarious way.

Seriously, just change the one character I mentioned originally and it resolves everything..
1

#10 User is offline   yadny 

  • Pip
  • Group: Members
  • Posts: 4
  • Joined: 2015-March-17
  • Gender:Not Telling

Posted 2021-December-14, 16:56

lol

I had seen that the error in the original post had been fixed, so I naively assumed that the error in my post was the result of an entirely different problem. it didn't occur to me that it was just the same problem as before
0

#11 User is offline   thepossum 

  • PipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 2,362
  • Joined: 2018-July-04
  • Gender:Male
  • Location:Australia

Posted 2021-December-19, 01:32

View Postsmerriman, on 2021-December-14, 14:04, said:

Yep, BBO tried a different fix that doesn't work at all.

Their change: if a +/-/= box has already been added to the card, then don't overwrite it with another one.

This works in the original example since the order returned by the DD analysis is 8, T, A. So after it calculates the results for the 8 (=), it doesn't overwrite it when working on the T like it used to.

But in the most recent example, the order returned by the DD analysis is J, 9, 7. It calculates the results for the diamond J, thinks the diamond ten doesn't exist due to the off-by-one bug, and applies the same score to the 9. Now when it comes to the 9 loop, it has the correct value but the new code logic tells it not to override it with the right one.

In fact, take another look at my post above where I posted this sample hand that I expected to be broken before, but was working:



Lead the king of diamonds and press the GIB button to see the exact example I provided is now broken in a hilarious way.

Seriously, just change the one character I mentioned originally and it resolves everything..


Does anyone care about hands like this :)

In the broad though regarding DD, I am seriously curious about flawed statistical assumptions on small sims. I can't even be bothered to think about it, let alone challenge anyone
0

#12 User is offline   smerriman 

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

Posted 2021-December-19, 19:12

View Postthepossum, on 2021-December-19, 01:32, said:

Does anyone care about hands like this :)

No. It was a proof of concept (exemplifying the problem), not an actual hand.
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