[Bbradley62]

Trick 3: WestGIB pitches his ♠A. What's up with that?
http://tinyurl.com/3uhrmfa

[cloa513]

Bbradley62, on 2011-April-01, 19:03, said:

Trick 3: WestGIB pitches his ♠A. What's up with that?
http://tinyurl.com/3uhrmfa

Let along why it doesn't ruff and return a diamond (but that come down to signals which it doesn't do or read).
So so down against human lucky its played against robots.

[BunnyGo]

It was a misclick, obviously.

[cloa513]

Indeed opponents can ruff with every single trump or forcing a high ruff on one diamond and still cash the K♣. Not many hands are that much of a bloodbath.

[cherdano]

cloa513, on 2011-April-02, 21:41, said:

Indeed opponents can ruff with every single trump or forcing a high ruff on one diamond and still cash the K♣. Not many hands are that much of a bloodbath.

Let's not exaggerate. They can only take three ruffs plus a trump promotion. So West's slip only cost 4 tricks.

[Bbradley62]

Maybe the drop of the ♥Q under the ♥A on Trick 2 confused him?

[barmar]

My guess is it has something to with trying to avoid being end-played. Although I'm having a hard time coming up with a layout where that's an issue, since it can always exit with a spade AFTER winning the ace that it just threw away.

[phil_20686]

No, I'm certain the answer is that in all the Hands Gib sampled its play was irrelevant. I think its not too hard to come up with hands where discarding the spade ace is irrelevant. Either east or south having a spade void is enough probably.

I think looking for a hand where it gains is not necessary. If there are lots of hands where it doesnt matter, and GIB didnt sample any hands where it did matter, then it will play randomly.

[Bbradley62]

phil_20686, on 2011-April-06, 04:00, said:

Either east or south having a spade void is enough probably.

GIB's description of the 2♥ bid includes "1-3 S". I'm not convinced that it should, but it does. So, if WestGIB is only sampling hands that meet the bidding consraints, neither East or South can have a spade void.

In hands where a particular play is irrelevant 50% of the time and harmful 50% of the time, I find it hard to believe that GIB doesn't sample enough hands to get it right. In this case, I'd think that pitching the ace is harmful in the vast majority of possible hands, and irrelevant in only a small minority. There's no way GIB's sampling should have included only such a minority of hands. There has got to be a programming problem here.

[fred]

As I have tried to explain in other recent threads, when GIB does something apparently insane like this, the most likely explanation is that the GIB in question did not have enough time to figure out a reasonable play. When the time that GIB has is close to zero, the cards that it plays can appear to be more or less random.

Also as I tried to explain in other recent threads, the "basic robots" that one can rent with the web-client are especially vulnerable to not having enough thinking time to make at least semi-reasonable plays most of the time. I believe that the hand in question was played against such robots. The "advanced robots" are more expensive, but they are still a bargain (IMO) and their level of play is much stronger than those of the "basic robots".

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[gwnn]

Fred, you explained this well enough in the past threads. I think we all got it and we're happy to hear. I'm sure the advanced robots are much better and all robots will get better and better as processors grow faster and cleverer.

However, we're interested in some details, for example in this thread we were trying to come up with a good explanation. Even if GIB generated very few hands (say, four or five) to decide what to play on this heart, I think it is almost sure (more than 99.9%) that the pitch of the ace of spades did not turn out to be the best play, or even tied for best play. Especially as its constrains there appears a specification that declarer has at least one spade.

Could it be that GIB generated no hands at all to make this decision? Could it be that it generated some hands, but evaluated them incorrectly? Summed the evaluations incorrectly? Some other explanation?

[fred]

gwnn, on 2011-April-06, 08:27, said:

Could it be that GIB generated no hands at all to make this decision? Could it be that it generated some hands, but evaluated them incorrectly? Summed the evaluations incorrectly? Some other explanation?

Sorry but I can't answer this question properly as I don't know enough about the internals of how GIB works when it has very little time left (or no time left) out of the total thinking time we allocate for each deal and it has to decide which card to play.

I would guess that, however many hands it generated, it interrupted itself partly through the analysis of these hands and that the conclusions it draws in such scenarios are essentially random. I believe it is the case that GIB analyses such hands "all at once" instead of "one at a time" so it is not as if GIB would have the complete analysis of even one deal to fall back on if this process was interrupted.

I don't know what would happen if GIB did not have enough time to generate even a single hand, but I am sure it wouldn't be good. A semi-educated guess suggests to me that this was not the problem here.

The reason I am fairly confident that the problem on this hand is related to time is because we have done some experiments with hyper-fast GIBs. At some point the GIBs essentially become incapable of "following suit" (not in the literal sense!) - a significant percentage of the cards they play are absurd in these circumstances.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[helene_t]

but this happened at trick 3. Is it plausible that GIB had run out of time so early? If GIB runs on a slow computer (or gets allocated a small CPU slice by the flash engine, dunno if that can happen) would it play worse? Or are its resources measured in CPU cycles rather than seconds?

[fred]

helene_t, on 2011-April-06, 09:02, said:

but this happened at trick 3. Is it plausible that GIB had run out of time so early? If GIB runs on a slow computer (or gets allocated a small CPU slice by the flash engine, dunno if that can happen) would it play worse? Or are its resources measured in CPU cycles rather than seconds?

Uday would be in a better position than me to answer these questions, but I am fairly sure that the time GIB is given to think about each deal is expressed in (real) seconds. So if the CPU in question is under stress, GIB(s) running on that CPU would not be able to use this time as effectively as it would under "normal" circumstances.

The GIB in question was running on a server - the user's PC and Flash do not enter the equation. But various things can happen that result in these servers slowing down. I would guess that the most likely explanation would be a sudden spike in GIB-demand (which would force us to increase the number of GIBs on each server thereby decreasing the CPU resources available for each GIB per unit time).

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[Bbradley62]

fred, on 2011-April-06, 09:32, said:

I would guess that the most likely explanation would be a sudden spike in GIB-demand (which would force us to increase the number of GIBs on each server thereby decreasing the CPU resources available for each GIB per unit time).

This hand was played at 9pm (Eastern US) on Play-with-GIB-for-Free Day, so I'm sure demand was high.

[gwnn]

oh april fools! of course!

[barmar]

I played a hand tonight (ACBL Robot Duplicate) where GIB threw away a sure trick at trick 11. At this point, it should know where every card is.

http://tinyurl.com/3jofevo

All it has to do is play a low ♦, so that the 9 will take the last trick.

And my robot partner owes me a beer.