Open ThePokerDude opened 8 months ago
We need to add constraints like this to the new play engine
I do not understand yet the PIMC.py I think I got the concept of the constraints and how cards are removed from NS and opposHand (which is EW combinded) and then added to playedHand (which is all cards already played). But I don't get how the play is simulated. From the paper I understood that in PIMC you create a number x of deals according to the constraints.
Then you check with which plays you succeed for each of the deals. Afterwards you choose the play with the highest success rate.
For the last two lines I do not understand how they are implemented.
I can imagine (high level) that the problem could be solved like this. You do the finesse and win. You assume in your simulation that the opponent would take the trick in case the finesse would not work. Because of the assumption you remove the deals with failed finesse from your pool of possible deals. To meet reality you would not remove them but put a very low probability on them.
So in our case after crossing to dummy and playing low trump when the opponent follows suit, in the pool of deals you consider, finessing is the superior play.
To figure out what went wrong we'd need some detailed logging for each trick. Which deals are considered at trick two and how is the quality of playing queen or ace evaluated. Same for trick four. I think that in the log for trick four we'll find the solution for the bug. Maybe Ben doesn't remember the SQ is not in play anymore - then the playedHand implementation is not correct.
You assume in your simulation that the opponent would take the trick in case the finesse would not work. Because of the assumption you remove the deals with failed finesse from your pool of possible deals. To meet reality you would not remove them but put a very low probability on them.
So in our case after crossing to dummy and playing low trump when the opponent follows suit, in the pool of deals you consider, finessing is the superior play.
Sorry, but this is not in the implementation.
Interesting that WBridge5 did not cover the Diamond lead.
This is the score at trick 5
and SA will ensure the contract based on the simulated deals, where the finesse might lead to defeat.
This is the constraints
So of the possible 24.310 combinations it evaluated 3581 and discarded 3389.
But it would be nice if we could add some constraint on SK.
This is the worst declarer play I've seen from Ben. Ben takes the finesse (works), goes to dummy to repeat it and then plays SA.
[Event ""] [Site ""] [Date ""] [Board "177"] [Dealer "E"] [Vulnerable "None"] [Deal "E:AQJT2.3.AJT93.86 7.Q987654.5.QT93 865.AK.Q72.AKJ72 K943.JT2.K864.54"] [Scoring ""] [BCFlags "1f"] [Generator "BridgeComposer Version 5.104.1"] {PAR of the deal: 7NT = played by east: 1520 points} {Feasability: 1 0 6 0 0 12 13 7 13 13 1 0 6 0 0 12 13 7 13 13 [South "WBridge5"] [West "ben0308p5dd"] [North "WBridge5"] [East "ben0308p5dd"] [Declarer "E"] [Contract "6S"] [Result "11"] {PAR of the deal: 7NT = played by east: 1520 points} {Feasability: 1 0 6 0 0 12 13 7 13 13 1 0 6 0 0 12 13 7 13 13} [Auction "E"] 1S Pass 3C Pass 3D Pass 3S Pass 4S Pass 4NT Pass 5S Pass 6S Pass Pass Pass [Play "S"] d5 DQ d6 D3 s7 S6 s4 SQ c9 CA c5 C6 h4 S5 s3 SA h5 S8 sk SJ hq D7 s9 ST h6 D2 d4 DA c3 CK c4 C8 ct C7 d8 S2 h7 HA h2 H3 cq C2 dk D9 h8 HK ht DT h9 CJ hj DJ