segal2@husc4.UUCP (Jonathan Segal,B13 Sci Ctr,51263,) (01/08/90)
From article <9001052127.AA11393@cds574.noble.com>, by twk@cadence.com (Tom Kronmiller): > The editors of The Bridge World did a pair of articles in the October '89 > and November '89 issues, discussing the state of computer bridge playing > programs. This is what prompted my original query on the subject. [summary of the state of bridge playing programs omitted...] I am thinking of writing a bridge playing program. This will be my first foray into complicated ai, so I am asking for ideas from people. Basically, I would like the program to be flexible (able to play different conventions/systems), so a general formalized description of bidding needs to be developed. (Actually, a formal description of hand features which one would use in deciding what to bid is also needed). A simple example of this is the point count. A more complicated example is (and I'm not sure how to formalize this conveniently) holding Kx in a suit can be a stopper in notrump if the lead is coming up to it, rather than through it. This, along with a good, formal system-description language (and maybe (certainly) other features) would be needed to write the bidding part of a program. For the play portion, aside from the mechanical card play simulator, one would want an inference making system, and (probably) some heuristic "card-state-space" searching, to "anticipate" the play several tricks down the line (for various possibilities of hands which fit the previous bidding and play, etc.). I would want it to also have some formal description of various "expert" plays -- endplays, squeezes, etc., though those may not be as necessary with a good searcher, as they would "come clean in the wash," so to speak. I may want a learning (self-teaching) system superimposed on the above. (Or maybe it will be the above superimposed on a learning system?). I am not sure if it would be easier or harder (or necessary) that way. Also, the bidding and play portions would certainly need to "talk" to each other, just as when you or I play bridge (one visualizes the play of the cards when bidding, and uses clues from the bidding in developing the play...) As is clear, this "project" is in a very early stage of development. (If it can be called a stage of development...) I am currently brainstorming various solutions to the above questions, (and also more questions). Therefore I am soliciting advice from the net. If anybody has any ideas on any factors of any of the above "questions" (nebulous though they are), or any new questions which need to be considered, please post or respond via email to segal@zariski.harvard.edu. Any and all help will be greatly appreciated. > > The bottom line seems to be that no one has a good bridge player program > out there, but other bridge tools are available and work pretty well. > Maybe I should post to comp.ai a request for someone to write a > good program.... I think I'll even cross-post.. Needless to say, the task is quite formidable. I am not sure I'll be able to do it, but it doesn't seem like the task should be impossible. > > ....since we always seem to have one player too few! > > Anyway, thanks to all of you who replied! > > --Tom Kronmiller (twk@cadence.com) Thank you Jonathan Segal (segal@zariski.harvard.edu) (segal2@husc4.harvard.edu) P.S. The bridge scoring (for imp pairs/mp pairs, etc.) which I have written and posted a message about several months ago is still available. (BTW to gonzo%contact%becker%mnetor@cs.toronto.edu -- I've tried getting it to you several times, but things have bounced. could you send me an address where you can be reached (rather than having me try to decipher it from the mailer) -- If worse comes to worse I suppose I can post, but I'd rather use email if possible) -Jonathan Segal JAS segal@zariski.harvard.edu segal2%husc4@harvard.ARPA segal2@husc4.harvard.edu segal2@husc4.UUCP segal2@HARVUNXU.BITNET ..{seismo, harpo, ihnp4, linus, allegra, ut-sally}!harvard!husc4!segal2 andardstay isclaimerday