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".]