![]() |
Deal 3.0 - New Features
|
This means that the first time you pass the string "AK4" to a Deal procedure, it will parse it into an internal represention, and then never parses it again. The internals of Deal now take advantage of this in quite a lot of places.
We compute the high card points as 7, 6, 0, and 4, in spades, hearts, diamonds, and clubs, for a total of 17 points. We compute losers in the suits as 1, 1, 3, and 2, for a total of 7 losers.Spades: AKx Hearts: KQJ Diamonds: xxxx Clubs: Axx
In Deal 2.0, you could define a very limited set of procedures of this sort - the so-called vector procedures. You could, for example, define "high card points" or "controls," but not "losers."
In Deal 3.0, virtually any such procedure can be written.
See seperate document for more details.
See separate document for details.
To access an input format, you can either add the line:
or, from the command line, use thedeal::input formatName [args...]
-I
switch:
Deal 3.0 includes the following input formats:deal -I "FormatName[ args...]" ...
line
-l
flag. For example, you can generate a file of 1000 deals then run two
seperate queries on the file with:
If no file is given, the lines are read from standard input.deal -l 1000 > sample.txt deal -I "line sample.txt" -i query1.tcl > out1.txt deal -I "line sample.txt" -i query2.tcl > out2.txt
giblib
gib::tricks
take the data from this file, rather than calling the double-dummy
solver.
If no file is given, Deal looks in the current directory for a file nameddeal::input giblib [filename]
library.dat
.
The data file is not included in this release - it's really huge. See the GIB research project page for more details.
smartstack
smartstack
is to find certain rare
types of deals very quickly, not using the standard dealing techniques,
but using a more complicated and data-heavy approach.
Smart stacking
is documented
seperately below.
input/Foo.tcl
which contains a Tcl package named Foo
with procedures called set_input
and next
.
See the input formats included with Deal for examples.
The next
procedure should return an error when it has
reached the end of input.
An input format does not have to read from a file. For example,
the smartstack
code is a factory which builds deals
on the fly with one hand fitting a certain condition.
Suppose we want north to have a balanced hand with 22 or 23 high card
points. We can force this
by using the smartstack
input format:
The arguments tell the stacker to randomly build north hands that are balanced with high card points in the range of 22 and 23.deal::input smartstack north balanced hcp 22 23
Any shape class can be used in the place of balanced
,
and any holding procedure can be used in place of hcp
in the above example. If an evaluator is not passed in, there
is no range requirement. If you wish no shape restrictions,
use the shapeclass AnyShape
.
Specific cards can still be placed in specific hands:
Smart stacking can also put restrictions on specific suits:deal::input smartstack north balanced hcp {20 21} south is K52 KJ3 98542 AK north gets AS QS QH
This requires north to have 2-3 controls in diamonds.deal::input smartstack north balanced hcp 20 21 smartstack::holding diamonds controls 2 3
The tighter the restrictions, the faster Deal will be able to build hands which satisfy them.
Any additional conditions you want to place on any of the hands can
still be placed in main
, as usual.
ex/1-shapeclass.tcl
in the release
has no startup
time, and takes about 0.014 seconds per match found. The equivalent
script using smartstack
, ex/1-stack.tcl
,
takes almost 13 seconds at startup
time, but then takes onlu 0.002 seconds per match found. So
if I'm generating 10,000 with these deals, it takes about
36 with smart stacking, and about 140 seconds without. But if
I'm generating 1,000, they take about the same time, and if I'm generating
only 10, using smart stacking is costly.
Is smart stacking ever useful when dealing with small sample requests? Definitely - if the hand is *very* specific and/or rare. For example, the two above scripts use a point range of 11-15, but if they are changed to seek 21-22 hcp hands of the same shape, they both take about 10 seconds to find 10 deals, but the smart stacker takes only 14 seconds to find 1,000, while the standard algorithm takes 1,000 second!
Originally, I was going to call the "smart stacker" by the name, "deal factory." Like a real world factory, there is a large startup cost, but after it is built, it builds deals to specification far faster. The more specific your needs and/or the larger supply you need, the more useful that initial investment is.
If I use smartstack to generate balanced hands with 20 points, it has a startup time of about 20 seconds. If I request balanced 25-counts, 17 seconds, balanced 29-counts 12 seconds. After startup, the amount of time to find examples is almost nil. Without smartstack, it takes about five minutes to generate ten examples of balanced 29-counts. With smartstack, only 13 seconds.
For the evaluator, don't use one that has too many possible values,
or the size of the stacker's table balloons horribly.
For example, in each suit, the values possible for hcp
are
0-10. But if you were to use something really complex with floating
point values, you might screw the pooch. No smart checking is applied
when building the table, either, so Deal might just appear to churn.
![]() |
Thomas Andrews
(thomaso@best.com)
Copyright 1996-2002. Deal is covered by the
GNU General Public License.
Plane Dealing graphic above created using POV-Ray. |