[helene_t]

hrothgar, on Jul 5 2010, 06:05 PM, said:

I'd like to repeat a comment from the first page of this thread: Start by modeling auction termination before thinking about opening structures.

Fair point.

My algorithm decides on the final contract immediately after the opening bid, so rather than making it make that choice after having heard an opening bid optimized by the procedure, I could make it make the choice after having heard, say, partner opening a standard preempt. This is not interesting in itself though since this is what (for example) GIB already does all the time.

Then the next step is to make a strategy for responder for choosing with which hands it must place the final contract and with which hands it must make a forcing bid.

[tysen2k]

helene_t, on Jul 3 2010, 09:10 AM, said:

Is there any way the computer could learn to construct openings like the multi 2♦?

There are plenty of dummy variables that you can add besides raw suit lengths.

• Length of longest suit
  
• Length of longest major
  
• Length of longest red suit
  
• Length of shortest major
  
• Number of doubletons
  
• Number of singletons
  
• Number of voids
  
• etc.

Tysen

[hrothgar]

tysen2k, on Jul 5 2010, 08:34 PM, said:

hrothgar, on Jul 5 2010, 10:05 AM, said:

I'd like to repeat a comment from the first page of this thread:  Start by modeling auction termination before thinking about opening structures.

Conceptually, auction termination seems like a much easier problem.

Do you propose solving auction termination in general? Only in a relay context? Are you talking about something that can handle any starting level and any known info about partner's hand?

Tysen

My preference is (almost) always to start with the simple and build to the complex:

Here's what I would find especially interesting:

Start with the following relay example:

RR has just bid 3♦ showing precisely

3=5=1=4 shape
6+ Slam points
9 - 14 HCP

The relay captain has a hand that

1. Is going to want to play in Hearts
2. Wants to explore 6♥ as a contract

See what the NN comes up with in terms of methods...

Once the network has converged on something, the next thing that I'd look at is the sensitivity of the resulting solution by changing the relay captain's hand.

Make sure that Hearts are still the best trump suit.
Include the same basic choice between game and slam.

Compare the two solutions and see how different the methods are...

[tysen2k]

Let me just say that I'm glad we're brainstorming here and all coming up with different ways of handling the same problem. I'd like to encourage others to try their own methods too.

Tysen

[hrothgar]

tysen2k, on Jul 5 2010, 09:09 PM, said:

Let me just say that I'm glad we're brainstorming here and all coming up with different ways of handling the same problem. I'd like to encourage others to try their own methods too.

Tysen

Regretfully, I am completely buried at work right now
(Mid Year advisory + I'm prepping a lecture at Lawrence Livermore next week which involves lots of brand new content. Should be a fun talk - certainly a fun topic - but the audience is imposing...)

If I ever manage to extricate myself, I might see what some of our machine learning algorithms are able to come up with...

[NickRW]

hrothgar, on Jul 5 2010, 05:59 PM, said:

My preference is (almost) always to start with the simple and build to the complex:

Here's what I would find especially interesting:

Start with the following relay example:

RR has just bid 3♦ showing precisely

3=5=1=4 shape
6+ Slam points
9 - 14 HCP

The relay captain has a hand that

1. Is going to want to play in Hearts
2. Wants to explore 6♥ as a contract

See what the NN comes up with in terms of methods...

Once the network has converged on something, the next thing that I'd look at is the sensitivity of the resulting solution by changing the relay captain's hand.

Make sure that Hearts are still the best trump suit.
Include the same basic choice between game and slam.

Compare the two solutions and see how different the methods are...

Yeah - simple is good - and the example interesting. But, what are we trying to do here - get a computer to design or assist in the design of a system - or are we getting it to play said system as well - you seem to be in the latter camp.

Assuming for a moment that I am in that camp, I would like to know how a computer would know it is "captain" or not inherently - i.e. not with some procedural code that follows the rules of a pre-designed system. In other words, I don't know of an example of learned captaincy as emergent behaviour from any sort of AI. Perhaps I am just uninformed - if I am, then please refer me to whatever research papers there are about it - as I'd be enormously interested.

Nick

[bab9]

NickRW, on Jul 5 2010, 03:48 AM, said:

The above figures are out of just over 700K boards (Matt Ginsberg's dd database).

Nick

Is this database available to others? If so, how do we get a copy/access?

[helene_t]

bab9, on Jul 6 2010, 03:40 AM, said:

NickRW, on Jul 5 2010, 03:48 AM, said:

The above figures are out of just over 700K boards (Matt Ginsberg's dd database).

Nick

Is this database available to others? If so, how do we get a copy/access?

http://cirl.uoregon....ibresearch.html

Btw, Daniel Winograd-Cort's thesis is related to what we are doing here. He is using neural networks to identify features of two combined hands that are relevant to bidding:
danwc.com/uploads/publications/DWC_Bridge_Thesis.pdf

Nick said:

But, what are we trying to do here - get a computer to design or assist in the design of a system - or are we getting it to play said system as well

Well speaking for myself I would say that the computer should defently be able to play the system, otherwise it would not be very interesting.

But once the system has been designed, getting the computer to play it will be a trivial task compared to the effort of designing the system. OK it may not be completely trivial since there may be situations where the system doesn't prescribe a call but the player has to use judgment - but still that is much simpler than the process of designing the system.

Besides, the optimization algorithms presumably have to bid the hands in the training DB in order to steer the training process so most likely the computer can bid the hands to begin with.

[ccw]

I've often thought about this from what seems to me like another perspective: Teach the computer how to efficiently encode information and then have it chose a definition of bids depending upon the auction thus far (with partner doing the same thing of course) Then make the bid representing the partition into which it's hand falls.
Make the cheapest bids represent the largest bins

The idea would be to use something much like arithmetic compression where the transmitted symbols are the bids and the model used to estimate the probabilities of various hands is based on some assumptions about the auction so far.

Of course this may not get you to a playable contract but it will take advantage of the computer's strengths.

Getting to a playable contract would need to take the weakest hands (by what metric?) and put them at the cheapest call (pass).

Just something I daydream about as I mow my lawn...

[hrothgar]

NickRW, on Jul 6 2010, 03:36 AM, said:

Yeah - simple is good - and the example interesting. But, what are we trying to do here - get a computer to design or assist in the design of a system - or are we getting it to play said system as well - you seem to be in the latter camp.

My "interest", so to speak, is academic at best.

To the extent that I have a dog in the fight, I am primarily interested in understanding the limitations of the methodology being used.

Regardless of what answer the various algorithm's output, my immediate reaction is going to be to try and determine whether or not its safe to trust this information.

In turn, this means understanding the stability of the solution.

From my perspective it makes sense to do some preliminary investigating on the front end before immediately wading into the thick of things.

[NickRW]

hrothgar, on Jul 6 2010, 12:24 PM, said:

Regardless of what answer the various algorithm's output, my immediate reaction is going to be to try and determine whether or not its safe to trust this information.

I suppose we can define that, at least for examples such as yours, trustworthy = min IMPs not lost compared to DD result - which is trivial to measure - or it is assuming you have two constructive bidding systems to compare.

In the more general case, you can't simply have a system that simply bids constructively as it would be too easy to exploit... You then get into what is optimal strategy - and that, for a bidding system, would be enormously difficult to determine I think. For my part, my aims are simpler - does it look playable!

Nick

[tysen2k]

helene_t, on Jul 5 2010, 09:19 AM, said:

I have now made a tree based on Tysen's reward function.

Okay, here's an interesting thing that I noticed about this. Look through the tree at all the places where it asks for information about the same feature twice (It asks about spades when it already asked about spades previously).

I count 32 times where this happens. In 23 of those cases (72%) the question was asked again when a low answer was given to the first question. So "I'm weak" "Really? How weak?" was more common than "I'm strong" "Really? How strong?" Same with "I have short spades" "Really? How short?"

Is this an artifact of the setup, or is there more value in telling partner what you don't have?

Tysen

[helene_t]

Intriguing observation.

It could be that there is a left-skewed gain function related to cut-offs, so that the best cut-off is likely to make a small "low-value" subtree in terms of probability mass and that the second-best split then is to the left of that in general.

For example the root split of <4 hearts send more hands to that left than to the right (you have 4+ hearts less than half the time).

But on the other hand the first HCP split is always <10 HCP which sends slightly more hands to the right.

I can't think of any particular reason why it would show the a bias you observed. It is also a little complicated because responder will use negative inference, for example take a shot at a diamond contract when opener's lengths in spades, hearts and clubs are all constrained.

Sorry I am going on holidays now and wont have access to high-performance computers for one and a half week so I won't do any more simulations in that time.

[NickRW]

tysen2k, on Jul 6 2010, 10:11 PM, said:

Is this an artifact of the setup, or is there more value in telling partner what you don't have?

Tysen

Part of the problem - if it is a problem - is the way the Helen's system is presenting the data. What I mean is that, if you study the part of the tree that is H<4, S>=4 (the second quarter left to right basically), at some points it asks, "do you actually have 5 spades". There are also a few branches where this question is not asked, but, if you study what minors it also can't have along with the not 4 hearts, actually they really do mean 5 spades as well - in fact one branch actually implies at least 6 spades. 5 spades being important is a familar concept to human bidding system designers, of course.

Looking at the data I've got, I can see why Helen's model is splitting, points wise, on P=0-9 versus P=10+, coz I get essentially the same split in the bid constructively versus pass or preempt decision. (There are some typically 4333 shapes it suggests waiting for 11 and some long major cases where it thinks 9 or even less is OK to bid constructively with - but the general split is a 10 versus not 10hcp).

I guess it should be noted that both the data I am using and the way I think Helen's stuff is working is very frequency oriented. Traditional bidding systems mainly centre on waiting for about 12hcp or maybe a little less with compensating shape - and are very much geared around the concept of 2 opening hands = game - and it is safe to pass less than this because if P can't open either you won't miss a game. That is essentially an IMP oriented strategy. Whereas what we are doing is frequency based - and probably therefore likely to be suited to MPs.

At the moment I'm looking at Helen's P=10+ cases (effectively shifting that decision to the top of the tree) and seeing what it has to say about useful shapes). Maybe I might post something about it - or there again...

Nick

[NickRW]

NickRW, on Jul 7 2010, 01:28 AM, said:

At the moment I'm looking at Helen's P=10+ cases (effectively shifting that decision to the top of the tree) and seeing what it has to say about useful shapes). Maybe I might post something about it - or there again...

Crudely speaking Helen's tree, for the 10hcp+ cases anyway, breaks down into about one quarter denying a 4 card major and subsequently focusing on whether there is a 5 card minor. Much of the rest focuses on if there is a 5 card major or not. It isn't as complex as it looks.

Where it really gets controversial is that you can take this as evidence to support 5 cards majors - or 4 card majors - or a MOSCITO style or whatever spin you want to put on it really!

Nick

[bab9]

tysen2k, on Jul 6 2010, 05:11 PM, said:

helene_t, on Jul 5 2010, 09:19 AM, said:

I have now made a tree based on Tysen's reward function.

Okay, here's an interesting thing that I noticed about this. Look through the tree at all the places where it asks for information about the same feature twice (It asks about spades when it already asked about spades previously).

I count 32 times where this happens. In 23 of those cases (72%) the question was asked again when a low answer was given to the first question. So "I'm weak" "Really? How weak?" was more common than "I'm strong" "Really? How strong?" Same with "I have short spades" "Really? How short?"

Is this an artifact of the setup, or is there more value in telling partner what you don't have?

Tysen

I have read about conventions that look later in the auction at first round controls and then ask the question is this due to an ace or a void. One implication of the decision tree may be the asking/giving this shortage information eariler in the bidding process.

Perhaps there is a lot of value telling partner what you don't have, given that conventions have been developed to show shortage, eg splinters.

[helene_t]

NickRW, on Jul 7 2010, 03:56 AM, said:

Crudely speaking Helen's tree, for the 10hcp+ cases anyway, breaks down into about one quarter denying a 4 card major and subsequently focusing on whether there is a 5 card minor.  [.....]
Where it really gets controversial is that you can take this as evidence to support 5 cards majors - or 4 card majors - or a MOSCITO style or whatever spin you want to put on it really!

I think it is understandable if this crude approach leads to something more akin to 4-card majors (or maybe 3-card majors) than 5-card majors, for three reasons.

First, although the node-to-bid assignment will (implicitly) give a small reward for natural bidding because 1♠ is a great opening whenever it allows partner to guess that 1♠ is the par result, this is a very small reward so you wouldn't expect the system to be natural except maybe that the 2-openings would tend to have some length in the suit they open. But one argument for 5-card majors is that in a natural system, showing majors take up more space than showing minors so must be more specific.

Second, one argument against 4-card majors is that in a system with longest-suit-first and a natural notrump opener, you often won't be able to show your 4-card major anyway because the system will prescribe some other opening. But there is no particular reason to expect the system to be longest-suit-first or to have a natural notrump opening.

Third, even if my reward function would make 5-card majors optimal, the algorithm might run into a locally optimal 4-card majors system because the first split will be on either HCP or 4-card majors for the simple reason that "spades<4" splits the set of hands closer to 50/50 than does "spades<5". Now in the "spades>=4" subtree you could split in "spades>=5" subsequently but that would not add much information so the next split is likely to be on a different variable.

[NickRW]

FWIW at this stage, I finally got my feature maps working something like properly. It seems to suggest that for a white vs white, aggressive and perhaps more MP oriented 1st seat system:

1) A weak 2♣ is not as LOL as some people might have thought
2) In contrast, a lot of traditional weak 2M hands, if you're going to be really aggressive, come within the band of what you should be regarding as a constructive holding.
3) Generally 10hcp is worth opening if you have a 4 card major, maybe wait for 11 without if bal.

What I've done does not suggest what to open with what - save for the highlight points above. However, the following relatively normal looking strong diamond system might be reasonable:

1♣ Minors or (14)15-17NT
1♦ Strong 18+bal, maybe 17 with a one suiter
1M, 10hcp+, 4+, can be as low as 8 with a 6 carder
1N, 11-13(14)
2♣, Weak, 6 cards, 5-9
2♦, Constructive 9-12 or so, 6 cards, could include 5=4 minors perhaps
Other 2s Polish style perhaps

Some of the above might test the patience of one or two regulatory bodies - the EBU wouldn't like rule of 17 one level openers iirc.

Nick

[Dirk Kuijt]

I'm working on a neural net attempt at this problem, so I'm bumping this topic. More to follow.

[Dirk Kuijt]

An update, but not a successful report.

I tried a Neural Net with these inputs:

HCP
# spades
# hearts
# diamonds
# clubs
and one input for all previous bids.

It was a failure. I couldn't teach the program anything.

I'm going to make a next try with:
several inputs for HCP, essentially as ranges
ditto for suit lengths
one input for each possible previous sequence.

We'll see how this goes. The number of possible sequences builds up very quickly, of course, so this may be unworkable from that respect.