early draft version of new research and programs
Alex Martelli
what else is there, and the strat1.txt is a VERY early draft for the
first-part of the article presenting early results of the research. If
you want the programs (MacOSX/Python 2.4.3 only), just get the zipfile,
it includes the .txt files too. The (10-MB!) .bz2 file has the 400,000
deals, with pointcounts and numbers of tricks for North declaring NT, on
which strat1.txt is based -- you may want it if you don't want to (or
can't, not having a Mac) generate/analyze other deals, and just want to
check the analysis etc (with the Python 2.4.3 programs that are in the
zipfile, and apart from DD analysis will run anywhere if Python 2.4.3 is
installed -- get it for free from www.python.org! -- or with other
devices of your choice, eyeballs included;-).
All 400,000 deals are constrained to N and S having 4333 shapes, N 15-17
HCP, S 8-10 HCP.
Feedback is welcome, either public or private! I do mean to keep
working on this stuff but, having a rather busy couple of weeks ahead, I
thought I should go ahead and make the current early drafts available.
Summary of results: strategy IJP (responded passes with 8, raises to 2N
with 9, to 3N with 10, and opener passes 2N with 15 but goes to 3N over
2N with 16-17) is optimal or close to optimal at both total points (V
and NV) and matchpoints/board-a-match; but many other strategies are
extremely close, including ones where responder never raises 1N to 2N,
and one such "bashing" strategy is superior to IJP at total points, V.
Anyway, this is just the beginning, of course -- just on the current
batch of 400,000 deals many more studies are possible (e.g.,
effectiveness studies of all kinds of other hand-evaluation pointcounts
and other strategies), not to mention studies of other NT ranges (I _am_
a weak notrumper by choice!-), other shapes (4432, 5332, ...), and other
situations yet, including completely different ones!
Alex
Otis Bricker
al...@mac.com:
> Summary of results: strategy IJP (responded passes with 8, raises to 2N
> with 9, to 3N with 10, and opener passes 2N with 15 but goes to 3N over
> 2N with 16-17) is optimal or close to optimal at both total points (V
> and NV) and matchpoints/board-a-match; but many other strategies are
> extremely close, including ones where responder never raises 1N to 2N,
> and one such "bashing" strategy is superior to IJP at total points, V.
>
> Anyway, this is just the beginning, of course -- just on the current
> batch of 400,000 deals many more studies are possible (e.g.,
> effectiveness studies of all kinds of other hand-evaluation pointcounts
> and other strategies), not to mention studies of other NT ranges (I _am_
> a weak notrumper by choice!-), other shapes (4432, 5332, ...), and other
> situations yet, including completely different ones!
>
>
Feedback:
While I can understand that you want to minimize the variables under test,
I still think that simply counting HCP and forcing 4333 shape makes the
results unrealistic.
Opener will rarely have 4333. 4432 and 5332 will be much more common. In
these cases, it will often matter more what sort of fit you have than the
exact number of HCP.
On the responder side, the same applies but to a slightly lesser degree
since 4432 with a major will be bidding Stayman.
I agree that the large sample does allow some interesting possiblities for
hand analysis. For example, comparing the results you just produced with a
strategy that passes 9 counts lacking some good "spots" and blasting with
hands that have the spots.
I'll leave the Python to you.
Otis
Alex Martelli
...
> While I can understand that you want to minimize the variables under test,
> I still think that simply counting HCP and forcing 4333 shape makes the
> results unrealistic.
To some extent, sure; that's a key part of the scientific method -- you
set up experimental or computational conditions that make your task
feasibly simple (by separating many different factors, generally present
in most real-life observations, that affect results in complex and
interacting ways), and thereby (to some extent) your results are
unrealistic -- they reflect your computational or experimental
simplifications. That's a strong part the conceptual breakthrough that
made modern science possible; for example, we would never have managed
to obtain the laws of motion without abstracting away SO much as to make
their direct application totally unrealistic.
Consider, for example:
"An object at rest or traveling in uniform motion will remain at rest or
traveling in uniform motion unless acted upon by a net force."
(This is Newton's phrasing, but Galileo's isn't all that different).
What's *realistic* about that? Where can this law's very strong
simplifying conditions be exactly applied?! And yet, this is the
cornerstone of our present understanding of motion.
I realize it's rather funny to compare oneself to Newton or Galileo, but
such objections make the temptation irresistible;-).
When it comes to real-world application of such principles (often known
as "engineering"), then determining which simpifications are
OVER-simplifications in a given situation becomes of course crucial. A
classic example (which brings us back to "bridge", in a sense;-) can be
studied at
<http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge#Cause_of_collapse>
-- effects such as second torsional mode and aeroelastic flutter COULD
be ignored (and routinely were) in bridge design (and other structural
engineering, I believe) until that famous episode.
But it's much too early to worry about higher-order effects, when we're
very far from having established the foundations!
This is all about the choice of 4333 shapes, which I believe is the key
simplification that makes the study possible at all. "Simply counting
HCP" is _not_ a key simplification here: any evaluation method that can
be applied algorithmically can be studied this way, and I do fully
intend to proceed in that direction. However, considering that 4-3-2-1
count is by far most widely used in these situations, it seems crucial
to first characterize its behavior, as the reference point against which
any other evaluation method can be measured.
> Opener will rarely have 4333. 4432 and 5332 will be much more common. In
> these cases, it will often matter more what sort of fit you have than the
> exact number of HCP.
Are you claiming that quantitative bidding of balanced hands is
impossible, or intrinsically inferior to "approach bidding" where suits
(and thereby to some extent fit) are revealed? That was, in essence,
Culbertson's early stance on Notrump bidding, but even he eventually had
to back off. There are all sorts of reason for that, of course, such as
the difficulty of bidding after a natural one-opener unless some range
of balanced hands are separated out into 1NT. It does seem a worthy
goal to study the extent to which this effect applies (to purely
constructive bidding with balanced hands: again separating out different
considerations for distinct study). For example, if it can be
determined that the effectiveness of quantitative bidding when opener is
4432 is markedly inferior to that obtainable when opener is 4333, that
is to some extent a vindication of Culbertson's theories, or at least of
those (now-rare) systems which open 1NT only with 4333, not 4432.
The pendulum's now swinging far in the other direction (and btw,
Galileo's observations about the pendulum were ALSO far too
simplified... good thing he didn't care!-), with 5422, 5332 with strong
majors, 6322, etc, being routinely opened in NT (particularly 2NT).
Again, finding out *how much* this affects constructive, quantitative
bidding seems a worthy goal. Ron Klinger insists on counting 5332 as
worth exactly one point (in his beloved Power system, 1NT is 17-20 with
4333 or 4432, but 16-19 with 5332) -- is he right? How do we KNOW,
without studying the effects in some way such as my research?
> On the responder side, the same applies but to a slightly lesser degree
> since 4432 with a major will be bidding Stayman.
But there are 4432's with both minors, which don't care about Stayman
(for simple game/no-game decisions -- we're NOT talking about slams...
yet!), and may still be studied quantitatively in similar ways.
> I agree that the large sample does allow some interesting possiblities for
> hand analysis. For example, comparing the results you just produced with a
> strategy that passes 9 counts lacking some good "spots" and blasting with
> hands that have the spots.
Sure, as long as ``having good spots'' can be quantified precisely.
There are many ways to do that, of course; the hard task is finding out
how good or bad different ways are.
> I'll leave the Python to you.
It's pretty hard to conduct such studies without _some_ programming. I
guess I might package things up into a GUI where one can enter some
numbers defining a quantitative evaluation (how many points, fractions
included, for each of various high or intermediate cards; thresholds for
responder to raise to 2NT and 3NT, threshold for opener to accept a 2NT
invitation) and just show how the results compare (total points, MP,
IMPs) against a "reference" (e.g., the IJP strategy with just HCP).
That would separate out the bridge part (trying out examples of a large
class of evaluation strategies) from the programming (which I could do
beforehand). But how many would be interested in downloading 10MB to
try out something that's STILL "oversimplified" anyway?-)
Alex
David Collier
> Check out <http://www.aleax.it/Bridge> -- the README.txt file summarizes
> what else is there, and the strat1.txt is a VERY early draft for the
> first-part of the article presenting early results of the research. If
> you want the programs (MacOSX/Python 2.4.3 only), just get the zipfile,
> it includes the .txt files too. The (10-MB!) .bz2 file has the 400,000
> deals, with pointcounts and numbers of tricks for North declaring NT, on
> which strat1.txt is based -- you may want it if you don't want to (or
> can't, not having a Mac) generate/analyze other deals, and just want to
> check the analysis etc (with the Python 2.4.3 programs that are in the
> zipfile, and apart from DD analysis will run anywhere if Python 2.4.3 is
> installed -- get it for free from www.python.org! -- or with other
> devices of your choice, eyeballs included;-).
>
> All 400,000 deals are constrained to N and S having 4333 shapes, N 15-17
> HCP, S 8-10 HCP.
>
> Feedback is welcome, either public or private! I do mean to keep
> working on this stuff but, having a rather busy couple of weeks ahead, I
> thought I should go ahead and make the current early drafts available.
I don't think it should be necessary to specify responder's strategy
at any point. I would suggest this alternative method:
Step 1: Decide what opener's strategy will be. For example,
you might say that opener will decline an invite with 15HCP
but accept with any 16HCP.
Step 2: Deal *one* hand for responder.
Step 3: Now simulate lots of possible hands for opener
consistent with responder's fixed hand. It is not necessary
(or desirable) to restrict this to 4333 shapes.
Step 4: Analyse these deals in order to work out what is
best for this particular responder's hand: should you pass,
invite, or bid game?
Step 5: Now return to step 2 and deal another hand
for responder.
After doing this you would be able to say something
like "60% of 9-counts should bid 3NT, 30% should
bid 2NT and 10% should pass." And you can also
quantify how much worse any other strategy would
be on average. Notice how this method takes into
account the fact that responder's hand evaluation is
not just a function of HCP without having to actually
write this into the program.
Then if you want you can change opener's strategy
to try and improve the overall expectation. Note that
a bad method of hand evaluation will make inviting
seem worse than it really is.
henry...@yahoo.com
5332 opposite 4333 or 4432 (no M) or 5332 (no M). That would mean that
we really have 6 scenarios:
4333 vs 4333
4432 vs 4333
5332 vs 4333
4432 vs 4432
5332 vs 4432
5332 vs 5332
In theory (?), one could tabulate the total outcomes and then break
them down by opener's or responder's shape as one wished.
Henrysun909
Tysen Streib
henry...@yahoo.com wrote:
> Presumably, one could run separate scenarios in which opener is 4432 or
> 5332 opposite 4333 or 4432 (no M) or 5332 (no M). That would mean that
> we really have 6 scenarios:
>
> 4333 vs 4333
> 4432 vs 4333
> 5332 vs 4333
>
> 4432 vs 4432
> 5332 vs 4432
>
> 5332 vs 5332
>
I would also filter it so that there is no 8-card major fit.
Invitational NT sequences can be used after Stayman/transfers. But
having the deals w/ 8-card fit in the them may skew the data. Hands
going through the NT invite sequence will thus be less likely to
contain a running suit, as is right.
Tysen
Otis Bricker
> Check out <http://www.aleax.it/Bridge> -- the README.txt file summarizes
> what else is there, and the strat1.txt is a VERY early draft for the
> first-part of the article presenting early results of the research. If
> you want the programs (MacOSX/Python 2.4.3 only), just get the zipfile,
> it includes the .txt files too. The (10-MB!) .bz2 file has the 400,000
> deals, with pointcounts and numbers of tricks for North declaring NT, on
> which strat1.txt is based -- you may want it if you don't want to (or
> can't, not having a Mac) generate/analyze other deals, and just want to
> check the analysis etc (with the Python 2.4.3 programs that are in the
> zipfile, and apart from DD analysis will run anywhere if Python 2.4.3 is
> installed -- get it for free from www.python.org! -- or with other
> devices of your choice, eyeballs included;-).
>
I think that the data file may be corrupt. Line 208547 is messed up in the
one I downloaded and I tried getting it twice. The line above it also seems
to be a duplicate of line 263705.
Otis
Alex Martelli
You're entirely right -- in fact, there are *1069* duplicates (!).
Sorry for not having checked things properly in advance. I'll
investigate things and try to upload a fixed datafile tonight (or, worst
case, tomorrow night).
Alex
Alex Martelli
...
> You're entirely right -- in fact, there are *1069* duplicates (!).
> Sorry for not having checked things properly in advance. I'll
> investigate things and try to upload a fixed datafile tonight (or, worst
> case, tomorrow night).
Fixed -- the datafile at http://www.aleax.it/Bridge/ now is correct (as
best I can determine). Thanks again to Otis Bricker for spotting the
problem (some lines damaged and some duplicated)!
Alex