[Bbradley62]

Trick 6... http://tinyurl.com/c3fwc6a

[Stephen Tu]

Is there much point to posting GIB's defensive blunders? There's pretty much nothing the developers can do about them, since GIB doesn't work by teaching it things like "third hand high"; it's just a Monte Carlo DD simulator. If it is constructing more hands where ducking is better, it's going to duck. The defensive errors boil down to:
- not being given enough thinking time
- very little defensive signalling, unable to bias the deals based on inferences of partner's and declarer's previous actions
- unable to treat declarer as non-omniscient, to give him problems.
- not generating right sort of hands for declarer, particularly if DB has holes, or declarer psyched or somewhat off-shape.

Unless someone is going to be programming at the level of Ginsberg and fundamentally rewrite the defense engine, the best we can hope for is plugging database holes, it can perhaps have a better estimate of what declarer can hold at best. It would be nice if they updated the download client more regularly instead of just the BBO server farm GIBs so we can run GIB slow on our own machines.

[cloa513]

Stephen Tu, on 2012-April-21, 18:59, said:

Is there much point to posting GIB's defensive blunders? There's pretty much nothing the developers can do about them, since GIB doesn't work by teaching it things like "third hand high"; it's just a Monte Carlo DD simulator. If it is constructing more hands where ducking is better, it's going to duck. The defensive errors boil down to:
- not being given enough thinking time
- very little defensive signalling, unable to bias the deals based on inferences of partner's and declarer's previous actions
- unable to treat declarer as non-omniscient, to give him problems.
- not generating right sort of hands for declarer, particularly if DB has holes, or declarer psyched or somewhat off-shape.

Unless someone is going to be programming at the level of Ginsberg and fundamentally rewrite the defense engine, the best we can hope for is plugging database holes, it can perhaps have a better estimate of what declarer can hold at best. It would be nice if they updated the download client more regularly instead of just the BBO server farm GIBs so we can run GIB slow on our own machines.

Its worse than DD simulator- its a double DD simulator- assume opponent GIB will play DD even though they don't.

[cloa513]

Stephen Tu, on 2012-April-21, 18:59, said:

Is there much point to posting GIB's defensive blunders? There's pretty much nothing the developers can do about them, since GIB doesn't work by teaching it things like "third hand high"; it's just a Monte Carlo DD simulator. If it is constructing more hands where ducking is better, it's going to duck. The defensive errors boil down to:
- not being given enough thinking time
- very little defensive signalling, unable to bias the deals based on inferences of partner's and declarer's previous actions
- unable to treat declarer as non-omniscient, to give him problems.
- not generating right sort of hands for declarer, particularly if DB has holes, or declarer psyched or somewhat off-shape.

Unless someone is going to be programming at the level of Ginsberg and fundamentally rewrite the defense engine, the best we can hope for is plugging database holes, it can perhaps have a better estimate of what declarer can hold at best. It would be nice if they updated the download client more regularly instead of just the BBO server farm GIBs so we can run GIB slow on our own machines.

But this error isn't signalling- its total blindness to the dummy's hand- there quite a few times GIB ignores the dummy hand and therefore the solution isn't GIB DD play- its a nonsense solution. They should be looking into the memory registers when GIB plays a hand like this and seeing whether it inputs the dummy into its solution. They should also turn maximum trick solution.

[EricK]

I think the problem with this hand is that GIB is assuming declarer can not be 5224 - so there is no useful discard on the ♥A and the ♦ loser can not run away.

[Bbradley62]

EricK, on 2012-April-22, 04:44, said:

I think the problem with this hand is that GIB is assuming declarer can not be 5224 - so there is no useful discard on the ♥A and the ♦ loser can not run away.

That would make it a toss-up as to whether to win the first diamond. My suggestion is that GIB should make the "standard" play unless there is a compelling reason to do otherwise.

[Stephen Tu]

EricK, on 2012-April-22, 04:44, said:

I think the problem with this hand is that GIB is assuming declarer can not be 5224 - so there is no useful discard on the ♥A and the ♦ loser can not run away.

That might be it. Giving PC GIB a less constrictive 1s-3s-4s auction, it takes the ace on the same defense. Also vs. the 1nt auction, if East cashes Qs first, or leads J of diamonds, the ace is taken.

Bbradley62, on 2012-April-22, 06:02, said:

That would make it a toss-up as to whether to win the first diamond. My suggestion is that GIB should make the "standard" play unless there is a compelling reason to do otherwise.

That doesn't work though, because GIB has no idea what a "standard" play is. It is essentially relearning the standard plays every deal, deciding that whatever play works best statistically on its sample is standard. It has no idea even what a simple finesse is.

More fuzziness on the declarer samples based on unreliable human bidding, or people who like to open 1nt all the time, is perhaps the only thing that might be able to be done by the current developers.

[cloa513]

EricK, on 2012-April-22, 04:44, said:

I think the problem with this hand is that GIB is assuming declarer can not be 5224 - so there is no useful discard on the ♥A and the ♦ loser can not run away.

It can see dummy includes Kx in diamonds and contains spades no DD analysis playing in trumps could possibly gain- I suspect GIB creators have mixed up NT DD and Trump DD when playing in defence where it could gain on NT play as a hold up play.