Another Robot joke

[xx1943]

Today I tried a slam in money-bridge.

I should have known better, bid 6♣ and the hand myself.

Perhaps 6♣ is the better contract anyway, so I got what I deserved.

 

There are 12 tricks from the top to take without finesse:

1♠+2♥+3♦+6♣

 

At trick 2 the GIB discarded one of his ♣-winners and went down 1.

 

I posted the hand on my blog.

 

Does anyone know, if the Gib's programmers are interested to know such happenings???

 

Regards

Al

[Rain]

Bug reports are appreciated, yes.

 

Not sure if this is a bug, but I'll send it on.

[helene_t]

It isn't necessarily a bug.

 

Roughly, for each decision, GIB makes a number of simulations of deals compatible with the bidding and play so far. He then choses a play that maximizes his average total points in those simulations.

 

What can happen is that some (say) 90% line happens to win in all the simulations. Then it may accidentally be chosen at the expense of the 100% line.

[matmat]

It isn't necessarily a bug.

 

Roughly, for each decision, GIB makes a number of simulations of deals compatible with the bidding and play so far. He then choses a play that maximizes his average total points in those simulations.

 

What can happen is that some (say) 90% line happens to win in all the simulations. Then it may accidentally be chosen at the expense of the 100% line.

I think that such an algorithm *IS* a major bug. I think that if it doesn't check for the presence for a 100% single dummy line first, it absolutely must.

[fred]

I think that such an algorithm *IS* a major bug. I think that if it doesn't check for the presence for a 100% single dummy line first, it absolutely must.

If you (or anyone else) can write a program that can do this accurately and quickly, we might be willing to buy it.

 

If you try I am betting you will fail (no offense to you - I don't think it can be done). Perhaps then you will be less inclined in the future to assert what our software "absolutely must" do.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[NickRW]

I believe many very clever people have tried to solve this - and as far as I know the only reasonable solution is the simulation route - which normally works fine given that the bot has adequate cpu time to do enough simulations - but this is not easy to provide at trick one as there are many possible unseen hands and potential ways to play.

 

Nick

[jdonn]

To bad he didn't discard the diamond instead of the spade on the last club and find the squeeze on north.

 

Probably this could be programmed into GIB by sacrificing speed. I would rather an anamoly like this happen on very rare occasions than that GIB was slowed down on every hand. By a mile.

[Echognome]

I will certainly plead ignorant to how the code works and do not have any expectations about how it should work.

 

I think it would be great though if someone could figure out a way to program a TopTricks function. It could be a route to allow GIB to claim. The measure could be a conservative one initially. Playing in NT, GIB could count it's Aces. Then if it has the King in the same suit, it could count that. Then if it had the Queen it could count that. Etc. Then it could extend to "sure tricks" via length. Again, only in top tricks, not if you have to lose a trick first. Then you could expand it to trump contracts and count TopTricks after drawing trumps. I think it would take a bit more yet to figure out TopTricks on say a cross ruff though.

 

Down the line, perhaps it can be programmed to update TopTricks, given the tricks that have been played. By that I mean, say GIB has the J in a suit and the A, K, and Q have been played, then it knows the J is high. Maybe some of that is already built in. I just don't know.

 

Finally, once TopTricks = RemainingTricks, GIB can claim.

 

Some of the calculations seem "easy" to me and others seem a lot more difficult. I just don't know how it's coded to know how difficult it is to implement.

[barmar]

The TopTricks function sounds like a good avenue, but even that has some gotchas, like blocked suits. I'm not saying it's not feasible, but it's also not as simple as it seems.

[jdonn]

The TopTricks function sounds like a good avenue, but even that has some gotchas, like blocked suits. I'm not saying it's not feasible, but it's also not as simple as it seems.

Blocked suits. What to discard on the winners. Making sure AK opposite QJ is not 4 tricks. The extra time it would take to run when it won't even matter on over 99% of the hands.

 

Back to the drawing board...

[matmat]

I think that such an algorithm *IS* a major bug. I think that if it doesn't check for the presence for a 100% single dummy line first, it absolutely must.

If you (or anyone else) can write a program that can do this accurately and quickly, we might be willing to buy it.

 

If you try I am betting you will fail (no offense to you - I don't think it can be done). Perhaps then you will be less inclined in the future to assert what our software "absolutely must" do.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

i think i may have misstated what i meant.

 

it strikes me that it should not be too difficult to write a piece of code that will count the number of top tricks available to cash and if that number is equal to the number of tricks left, then claim/cash the rest.

 

I am not saying there must be a single dummy solver. that's hard.

[uday]

Most of our energies to date have been spent on making GIB saner in the bidding ( we have a new release, thanks to Ari G. that you rate to see in about a week - it will be bundled with some other updates ).

 

I have seen this sort of bad play before. The usual case involves GIB taking a line for overtricks and going down against an unlikely lie of the cards

 

GIB is able to play the cards better --- but it will be slower. Thats the tradeoff. Should we tell GIB to take more time on games and slams ? Hmm. I dont dislike that. The amt of time GIB has to consider for the play is also affected by the amt of time it took in the earlier parts of the hand (example: the auction). it is also affected by the form of scoring.

 

I'll take a look at the actual hand to see why GIB did what it did and see what we can do about this, if anything. I know we tinkered with a version at some point that made it emphasize making the contract over making overtricks, but we never deployed it (mostly bec. I didn't quite understand my own changes).

 

 

U

[junyi_zhu]

Today I tried a slam in money-bridge.

I should have known better, bid 6♣ and the hand myself.

Perhaps 6♣ is the better contract anyway, so I got what I deserved.

 

There are 12 tricks from the top to take without finesse:

1♠+2♥+3♦+6♣

 

At trick 2 the GIB discarded one of his ♣-winners and went down 1.

 

I posted the hand on my blog.

 

Does anyone know, if the Gib's programmers are interested to know such happenings???

 

Regards

Al

I probably know what's going on. In Gib's simulations, even if it discards a winner, there is usually a squeeze in side suits for gib to make the contract. So git discards the club winner. However, gib never understands that bridge is a single dummy problem, not a double dummy problem, so it can never guess correctly every time. Actually a simple solution is not only to solve the current problem of the hands that are randomly generated, but also to solve the double dummy problem once a certain play is likely to be chosen, like the play of discarding the winner, then gib would generate more hands and sees the mistake in that certain play and throw it away. However, this simple approach would cost more computation time.

 

To make myself clear, let me give an example, in gib's mind, the two way finesse is 100%, cause gib plays a double dummy problem according to the hands it generated, but in real life, the chance is 50%, so gib should generate more hands once a certain finesse is taken, then it would understand that a two way finesse is not guaranteed.

[Echognome]

The TopTricks function sounds like a good avenue, but even that has some gotchas, like blocked suits.  I'm not saying it's not feasible, but it's also not as simple as it seems.

Blocked suits. What to discard on the winners. Making sure AK opposite QJ is not 4 tricks. The extra time it would take to run when it won't even matter on over 99% of the hands.

 

Back to the drawing board...

I don't think it would take very long to run it if it were limited in what it calculated. I believe it would be more than offset by the fact that it could now claim. In fact, I would think that a GIB claim should not be able to be disputed.

 

However, it's not me that has to program it, so I could easily be over simplifying what it would take.

[hotShot]

You have to understand that GIB does not know what a finesse or squeeze is.

[ochinko]

If Gib was able to count its top tricks (and I don't think blocking is that much of a problem because counting entries is trivial too) then it would actually spare quite a lot of CPU cycles as it wouldn't need to perform any simulations at all in cases like this.

 

I think Echognome is making a very good point. Single dummy analysis is a lot less useful in general, but it comes pretty cheap computational wise, almost free compared to simulations.

[Codo]

As a side note: I watch more human players who drop "sure" tricks in defence or in declarer play then Gib does.

 

He is much better in the area of real bad bugs then humans are.

Just follow the vuegraph and you see that even the best of us (read the ones much better then you and we) make dumb mistakes. They are few, but they are there.

 

So why do you bother about the bad play of GIB?

[ochinko]

I don't think you understand the issue. Gib has different modes depending on whether it is allowed to see all hands, or not. When you play with/against it, it doesn't know what is in the hidden hands, i.e. it plays fair, it only tries to "imagine" what is out there.

 

Whereas when you give it all the hands it performs a completely different job of analyzing the situation - double dummy on a known layout.

[helene_t]

For the purpose of avoiding going down when a 100% line is available, I think Josh is right. Anyway, Matt Ginsberg is a smart guy I am sure he has thought about this and had reason for the choices he made.

 

For the purpose of claiming (and accepting claims) it may have more merits, but I would be worried about players expecting GIB to accept all kind of claims that are obvious to a human but non-obvious to a computer, and then flooding Uday's mailbox when it doesn't.

 

Jack (and I suppose other bridge software) can claim and accept claims so obviously it is feasible. But GIB's CPU time is scarcer than that of single-user software, so I won't complain about GIB lagging behind other software when it comes to CPU-intensive features.

 

Someone suggested that instead of claiming, one could show one's cards to GIB to speed up his play. It certainly has merits and presumably would be easy to implement, but I wonder if it would be worthwhile. Screen real estate is a scarce commodity. A major concern in user interface design is to avoid clotting the screen with buttons which most users don't understand let alone use, and this is especially true for free entertainment software targeted at a relatively old and partly non-English-speaking user community.

[cherdanno]

Come on, GIB was going for the double squeeze and failed to realize that because of the blocked diamonds, dummy would get squeezed out of a threat first. Can you really blame him for trying to get into the bulletin?

[Codo]

Come on, GIB was going for the double squeeze and failed to realize that because of the blocked diamonds, dummy would get squeezed out of a threat first. Can you really blame him for trying to get into the bulletin?

Well he made it into the bulletin.. at least at BBF. Well done GIB!

[hotShot]

You may not be aware that this is a complex deal for GIB.

Since North is void in ♣ he's got a lot of legal cards that can be payed and the same is true for West (and South) in ♠ after the first round is played.

This means that GIB needs more time to double dummy solve the simulated deals. Since GIB operates under a time limit it's possible that GIB made his decision based on 1-4 simulated deals, giving these deals a lot of weight.

 

By the way if the time limit of GIB is fixed, GIB gets better with every card played, because with fewer cards the simulations are faster and GIB can simulate more deals during the limited time. More deals meant that the simulated deals are a better representation of the true probabilities.

[barmar]

As a side note: I watch more human players who drop "sure" tricks in defence or in declarer play then Gib does.

Of course, humans make lots of mistakes. But we expect different kinds of mistakes from computer and humans.

 

For instance, human players miscount, don't notice that someone has shown out of a suit, or don't realize that a spot card is high. It would be inexcusable for a computer to make mistakes like these, since it should have perfect memory.

 

This deal is an interesting case. To a human player it looks like a simple matter of counting top tricks. It seems like the kind of mechanical play that a computer should be able to do well. But it turns out to be harder for a computer than keeping track of all cards that been played.

 

Another thing GIB doesn't know anything about is safety plays.

[helene_t]

Another thing GIB doesn't know anything about is safety plays.

But GIB maximizes expected total points, doesn't it? So if a deal where the unsafe line goes down occurs once in its simulations, it should go for the safe line.

[barmar]

Another thing GIB doesn't know anything about is safety plays.

But GIB maximizes expected total points, doesn't it? So if a deal where the unsafe line goes down occurs once in its simulations, it should go for the safe line.

Safety plays tend to protect against rare lies of the cards, which may not show up in its simulations, or rarely enough that it doesn't swing the expected value enough.