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,005
  • Joined: 2006-June-16
  • Gender:Male
  • 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: 1,831
  • 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 online   smerriman 

  • PipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 2,301
  • 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 online   smerriman 

  • PipPipPipPipPipPip
  • Group: Advanced Members
  • Posts: 2,301
  • 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.
6

#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

Share this topic:


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