GIB makes DD error??
#1
Posted 2020-December-05, 08:26
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).
George Carlin
#2
Posted 2020-December-05, 10:13
But if I try to document this here (using Export -> Handviewer link etc.):
#3
Posted 2020-December-05, 13:10
So it must be an error at a later stage of the handviewer code.
#4
Posted 2020-December-05, 18:11
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.
#5
Posted 2021-September-08, 14:51
#6
Posted 2021-September-11, 16:53
bavard25, on 2021-September-08, 14:51, said:
Hi Bavard.
Woiuld you care to post a link to your deal too, where the DD analysis is still wrong?
#7
Posted 2021-December-14, 04:24
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
#8
Posted 2021-December-14, 13:41
#9
Posted 2021-December-14, 14:04
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..
#10
Posted 2021-December-14, 16:56
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
#11
Posted 2021-December-19, 01:32
smerriman, on 2021-December-14, 14:04, said:
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
#12
Posted 2021-December-19, 19:12