What's missing from online bridge dealing software?
#1
Posted 2014-May-21, 14:07
So this raises a couple of questions:
a) Are there any dealing programs I've missed which offer such an option?
b) Are there any other parameter-combinations missing from dealing programs that you'd like the option to specify?
#2
Posted 2014-May-21, 14:22
Jinksy, on 2014-May-21, 14:07, said:
So this raises a couple of questions:
a) Are there any dealing programs I've missed which offer such an option?
b) Are there any other parameter-combinations missing from dealing programs that you'd like the option to specify?
The dealer program that is integrated into BBO has a complete scripting language built into it
#3
Posted 2014-May-21, 15:36
Jinksy, on 2014-May-21, 14:07, said:
a) Are there any dealing programs I've missed which offer such an option?
b) Are there any other parameter-combinations missing from dealing programs that you'd like the option to specify?
condition hcp (north) > 17 or
(hcp (north) > 11 and hcp (north) < 15 and
spades (north) > 1 and hearts (north) > 1 and
diamonds (north) > 1 and clubs (north) > 1)
#4
Posted 2014-May-21, 17:15
Jinksy, on 2014-May-21, 14:07, said:
So this raises a couple of questions:
a) Are there any dealing programs I've missed which offer such an option?
b) Are there any other parameter-combinations missing from dealing programs that you'd like the option to specify?
As a project, you could write a program to "manage" scripting the dealer program on BBO. It is capable of reporting various forms of statistics. Two weeks won't be much time for a project like this unless you are pretty darn good at the language you are using.
That said, just because one exists should not stop you from writing your own. You could look at the links mentioned to see what BBO/Dealer support. You need to do several things - one generate random deals, two establish a mechanism for specifying constraints, and three establish whether a deal meets the constraints, and finally do something with what you got - report statistics or whatever. You might find that any one or two of those components might take a week or more.
Deciding how long software development takes experience. The best advice - predicting is hard, especially about the future - and software engineers routinely underestimate how long it takes to develop something.
Sounds like fun. Report back if you do something like this.
#5
Posted 2014-May-21, 17:25
If I'm practising, for instance, slam-potential hands in standard, opener will be for example 13-20 and responder 13-20. Unfortunately, because there are just more 13 point hands than 20, the dealer will present "at random" 60, 70% of the hands of the 1♠-2NT; 4♠ variety, and not enough of the "slam potential, but possibly 4 is the limit" hands that are the tough ones to handle at the table. If you push one hand or the other enough to get a large number of the borderline hands, you get way too many that are "6 or 7" hands instead, and you still aren't practising "borderline slam".
So it would be nice to say "13-20, but make the sets 13-14, 15-17, 18-20 equally likely" as opposed to the correct distributions given random chance.
#6
Posted 2014-May-22, 09:10
#7
Posted 2014-May-23, 03:06
condition: balanced (South) and 15<=hcps(South)<=17 and hearts(north)<5 and spades(north)<5 and picture(west,"J76-QJ32-K983-J9")
#8
Posted 2014-May-23, 18:32
helene_t, on 2014-May-23, 03:06, said:
condition: balanced (South) and 15<=hcps(South)<=17 and hearts(north)<5 and spades(north)<5 and picture(west,"J76-QJ32-K983-J9")
predeal north SJ76, HQJ32, DK983, CJ9
condition
shape (south, any 4333 + any 4432 + any 5332 - 5xxx - x5xx)
and hcp (south) > 14 and hcp (south) < 18
#9
Posted 2014-May-24, 07:15
FM75, on 2014-May-21, 17:15, said:
Not sure exactly what you mean. Do you mean something that would accumulate statistics over time? If so, to what end? Most of what I can think of that these could tell you would mathematically demonstrable outcomes that wouldn't benefit much from data.
Quote
Deciding how long software development takes experience. The best advice - predicting is hard, especially about the future - and software engineers routinely underestimate how long it takes to develop something.
Sounds like fun. Report back if you do something like this.
Yeah, I'm only just starting to learn, and the course progresses at a rapid rate, so I'm even less able to predict anything about scope atm. That said, the advantage of trying to create functionality that doesn't already exist is I'll be much more interested in carrying on with the task at the end of the two weeks. The course is one of the development 'bootcamps' that have sprung up in the last few years and doesn't grade or offer qualifications in any meaningful way, which has the upside that, while I might want some sort of feeling of accomplishment at the end of the last two weeks, I don't necessarily need to strive to artificially 'finish' the final project.
#10
Posted 2014-May-24, 07:52
Start with a good double dummy solver as your basic engine.
Build in logic so the engine is able to decide whether to continue to explore for slam or sign off.
Build in an interface such that you can easily input multiple auction termination methods.
Run the resulting systems over large numbers of hands and see which prove most effective.
#11
Posted 2014-May-24, 08:00
Jinksy, on 2014-May-24, 07:15, said:
Statistics of hand distributions meeting your constraints. For example, how likely were the hands to occur? What was the average, std deviation of each individual suit, points held, both individually and as partnership.
#12
Posted 2014-May-25, 18:34
FM75, on 2014-May-24, 08:00, said:
condition hcp (north) > 17 or
(hcp (north) > 11 and hcp (north) < 15 and
spades (north) > 1 and hearts (north) > 1 and
diamonds (north) > 1 and clubs (north) > 1)
action frequency "Table (2D) HCP North and South"
(hcp (north), 11, 25, hcp (south), 0, 20)
#13
Posted 2014-May-26, 00:52
I believe that the USA currently hold only the World Championship For People Who Still Bid Like Your Auntie Gladys - dburn
dunno how to play 4 card majors - JLOGIC
True but I know Standard American and what better reason could I have for playing Precision? - Hideous Hog
Bidding is an estimation of probabilities SJ Simon
#14
Posted 2014-May-26, 16:35
I remember using Chessbase 3 in early 90's and it was awesome. Sad that bridge software are 20-25 years behind.
There also should be an easy to use easy to import export dealer/simulation program. Not a script software.
For instance, he doesn't like being used as a human shield when we're being shot at.
I happen to think it's a very noble way to meet one's maker, especially for a guy like him.
Bottom line is we never let that difference of opinion interfere with anything."
#15
Posted 2014-May-27, 22:07
nige1, on 2014-May-25, 18:34, said:
condition hcp (north) > 17 or
(hcp (north) > 11 and hcp (north) < 15 and
spades (north) > 1 and hearts (north) > 1 and
diamonds (north) > 1 and clubs (north) > 1)
action frequency "Table (2D) HCP North and South"
(hcp (north), 11, 25, hcp (south), 0, 20)
As mentioned, Dealer has some pretty nice features built in. These make for an easier project that is still interesting. You could have plenty of fun "integrating" your application with an existing system. A good software developer is "constructively lazy". He/she does not reinvent the wheel, but "stands on the shoulders of giants".
Apologies for a truly "mixed metaphor" there.
#16
Posted 2014-May-27, 22:32
benlessard, on 2014-May-26, 16:35, said:
I remember using Chessbase 3 in early 90's and it was awesome. Sad that bridge software are 20-25 years behind.
There also should be an easy to use easy to import export dealer/simulation program. Not a script software.
You can use Deal MasterPro as a database program, it can also be used as a dealer and program, and has double dummy solving stuff.
I have Deal Masterpro, but I use excel for my database program, along with data grabbed from Double Dummy solver for par contract and makeable contact. And, of course, I have Bridgebrowser. It is really not hard to use, but, and this is a big but, YOU CAN NOT insert hands into it yourself. (neither can I). That, is a huge bummer. But since I have used two of the top of class programs (bridgeboreser, and Deal MasterPro), I can say that excel does a whole lot for you (but not scripting).
There is also an older database around (bridge manager), but it doesn't work with 64 bit computers, it is $20 I think. I happen to like the excel solution. Maybe it is because I am use to working in Excel. But I can paste into the forum, paste handviewer version into a browser, past a lin version into a text file and open with netbridgvu, double dummy solver, or bridge composer, I can pull hands by auctions 16 bids deep if I wanted to with no problem, etc. And now that I have the greasemonkey script, importing hands into the database is a piece of cake. 1eyejack wanted tag's for hands played on bbo, well you can add virtually unlimtied tags to the excel database as well.
Anyway, if you have questions about deal masterpro write me, and we can talk about what it can and can't do. I would like to hear about peoples experience with bridge manager.
#17
Posted 2014-May-27, 22:47
As already mentioned in the thread, the van Staveren dealer has most of the requested features for constraints and combinations... so too does the Thomas Andrews DEAL package. In the case of Deal, the front end can take any TCL command/subroutine/program you care to write - as, for instance, a branching routine that deals 12-14, 15-17 and 18-20 hands equally frequently, either with a random number generator or something like
set counter 0
main {
incr counter
set h [south hcp]
if {counter % 3 == 0} { reject if {$h<12} {$h>14}} { if {counter % 3 == 1} {reject if {$h<15} {$h>17}} {reject if {$h<18} {$h>20} } }
accept
}
It's really just a matter of what kinds of constraints you want to make easy for yourself, and what programming languages you know.
In my case, I taught myself TCL so I could use the Deal software. For basic statistics I use the built-in commands; for more complicated statistics I dump intermediate results from Deal to a .csv file that I can process in SAS (or the statistics program of your choice.)
#18
Posted 2014-May-28, 10:03
I guess I should give it a better try to dealmp.
Normally the excel-openoffice conversion is pretty smooth do you see any trap that could occur ?
For instance, he doesn't like being used as a human shield when we're being shot at.
I happen to think it's a very noble way to meet one's maker, especially for a guy like him.
Bottom line is we never let that difference of opinion interfere with anything."
#19
Posted 2014-June-16, 12:32
benlessard, on 2014-May-28, 10:03, said:
I guess I should give it a better try to dealmp.
Normally the excel-openoffice conversion is pretty smooth do you see any trap that could occur ?
In deal masterpro, you can enter upto 10 keywords for any deal. These are keywords you create. So you might gave one key word as play, another as defense. Then you might start creating all kind of keywords related to squeeze (simple squeeze, double squeeze, hedgehog, etc. You want a squeeze hand you might include Defense if you need to break up the squeeze on defense, or play if it is a find a squeeze hand. Still as a database DMPro is greatly limited.
#20
Posted 2014-June-29, 16:24
Siegmund, on 2014-May-27, 22:47, said:
It's really just a matter of what kinds of constraints you want to make easy for yourself, and what programming languages you know.
In my case, I taught myself TCL so I could use the Deal software. For basic statistics I use the built-in commands; for more complicated statistics I dump intermediate results from Deal to a .csv file that I can process in SAS (or the statistics program of your choice.)
Help! I am trying to make deal319 work on Windows 8.1 machine. What is the best way to learn enough TCL to make deal functional? Have a quant MBA background most familiar with excel, SAS, SPSS and GPSS, with a limited knowledge of command prompt, but little knowledge of other programming languages.