Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site grkermit.UUCP
Path: utzoo!linus!genrad!grkermit!chris
From: chris@grkermit.UUCP (Chris Hibbert)
Newsgroups: net.math
Subject: re: lotto odds
Message-ID: <426@grkermit.UUCP>
Date: Mon, 20-Jun-83 14:22:58 EDT
Article-I.D.: grkermit.426
Posted: Mon Jun 20 14:22:58 1983
Date-Received: Tue, 21-Jun-83 00:18:51 EDT
Organization: GenRad Inc., Concord, MA
Lines: 56

The following article appeared in the April '83 Issue of "Software
Engineering Notes, an Informal Newsletter of the ACM SIG on Software
Engineering".  I couldn't find a copyright notice, but the usual notice
in ACM SIG publications is something like: 

"Copyright 1983 by the Association for Computing Machinery, Inc.
Copying without fee is permitted provided that the copies are not made
or distributed for direct commercial advantage and credit to the source
is given."

			Fronton-Center Tickets for the Pick-Six Papers

In case you missed the brute-force example of almost-fail-safe
betting in the papers on 10 March 1983, it bears mention here for its
implications on fail-safe programming.  In Palm Beach Pick-Six
Jai-Alai, the jackpot payoff results from picking the winner of six
games each of which has eight teams competing.  Thus, there are 8**6
= 262,144 possible outcomes.   (The outcome of each game is  naively
thought to be relatively random, although years ago I did a little
calculation showing that there are surprisingly significant
probabilistic biases due to order -- even given equally matched
opponents.)    If no one gets all six winners exactly right, 25% of
the pool is split among the closest pickers, and the remaining 75% is
added to the jackpot payoff-- which accumulates.  On this occasion
the jackpot had gone untouched for 146 consecutive events, and had
built to $551,331.  A well-organized group of people placed 262,144
different bets ($2) -- covering every possible outcome at a cost of
$524,288.  The resulting payoff was $988,326.20 (the night's pool
[minus the fronton cut] plus all of the accumulated jackpot).  Thus
success depended critically upon no one else picking the winning
combination.  Even a two-way split resulting from a competing winning
ticket would have resulted in a $30,000 loss. (An off-night had been
chosen on which a small crowd would normally be expected to place
only about 10,000 bets -- covering a somewhat lesser number of
distinct combinations, with some replications.)  Well, you may ask,
what does all this have to do with software engineering?  The moral
of the story is that if superficial analysis shows you have covered
all your bets, you may still lose your shirt.  How do you ensure that
you got a ticket for each combination?  What if the ticket seller
dropped one [out of 262,144] on the  floor?   What if the
equipment malfunctions in the midst of betting?  What if you don't
finish placing all the bets in time?  (The process is still largely
manual , but now deserves an indivisible transaction "BET * * * * *
*".)  And now that this exhaustive strategy has been used
successfully, you also have to beware of someone else trying it on
the same evening as you!  Worse yet, if it were easy to make the
power-set bet, then you could probably not detect that someone else
was trying the same exhaustive strategy -- which tied up betting
counters for about half an hour at Palm Beach.  "Expect the
unexpected" is an adage given to system designers and programmers,
urging them to anticipate every possible unusual event.  But, as we
saw in the ARPANET collapse [Eric Rosen, SEN Vol. 6, #1, January
1981], for example, that means anticipating hardware problems as well
as algorithmic problems.  [I note in passing for those interested in
proving fault-tolerance properties that the word "admonish" means "to
reprove for a fault".]