Sap The game of SNAP is played with stadard decks of cards. The decks are shuffled ad cards are dealt simultaeously from the top of each deck. SNAP is called if the two dealt cards are idetical (value ad suit!). Here s the problem: what is the probability of gettig at least oe SNAP i a deal of the etire deck? Here I describe oe of the more iterestig sessios I had with this problem I started with the questio of whether the probability of gettig a SNAP should be greater tha or less tha /. That is, if you play the game agai ad agai ad each time have to bet o the outcome, how do you bet? After a small amout of arguig, they voted almost uaimously i favour of o SNAP. That is, they figured that you should get a SNAP less tha half the time. We the geerated some data. I put the 0 studets ito pairs ad had them play 0 games of SNAP each, of course stoppig if ever they got a SNAP, reshufflig, ad startig agai. Thus we had a total of 0 games of which 6 produced a SNAP, givig a estimate of the SNAP probability of 6/0 = 0.66. This was oticeably greater tha ½ they were quite surprised. [If you do t have eough decks of cards, a -card deck works well give each studet a complete suit, ad sap is called if the cards have the same value. Iterestigly eough, the aswer for the -card deck agrees with that for the -card deck to at least 0 decimal places! If you wat to kow why read o!] This is a old problem, but a good oe. It has a umber of classic variatios, for example if I have a umber of letters ad correspodig addressed evelopes, ad I put the letters at radom ito the evelopes, what is the probability that at least oe letter will get ito the correct evelope? It's especially good with cards, because the studets have some ituitio about what to expect, ad they ca gather lots of data quite easily. There are a umber of elegat solutios aroud, but this problem demostrates, I thik, the value i ot tryig to force your ow favorite techical trick o the class. (At least it did for me!) It also gives, at the ed, a ice glimpse of that mysterious umber e. I the posed the problem of how we might calculate the theoretical probability of gettig a SNAP. I gave them a few miutes to thik about this, but obody did very much. The all of a sudde Jeie arose from her seat, came up ad wrote a formula o the board. Jeie's formula. The SNAP probability is P = = 0. 66. Iterestig ad very close to the experimetal estimate too. The class looked at her with a mixture of puzzlemet ad awe. I asked for a explaatio. "Well, every time I put dow a card the chaces are / that my parter's card wo't be a match. Sice this happes times, the probability of havig o match o every card is (/). So the probability of havig a SNAP is mius this." Make sese? I asked the class what they thought; there was much ucertai oddig of heads, ad a lot of close studyig of me to discer what I thought. Sap //007
How might we evaluate such a argumet? Could we try it out i a simpler situatio where we might kow ahead of time what the aswer was? Someoe suggested we check it out with a smaller deck. For example, what would the formula give us for a deck of size? It would give P = =. But what is the SNAP probability for a deck with cards? It should be easy to work this out simply by lookig at all the possibilities. Ideed it is. With cards, either the two decks are i the same order, or they're reversed ad each of these is equally likely. I the first case there's a SNAP ad i the secod there is't, so P = /. Jeie s formula does't seem to work. Hmm. I order to focus the discussio, I asked whether ayoe could give me a -card sap situatio i which Jeie s calculatio would be correct with a aswer of /. Someoe came up with the idea of usig a coi istead of cards. If two players each had a coi, ad tossed them simultaeously, ad called SNAP if they matched, the what s the probability of gettig a SNAP i two repetitios of this? Well, with each pair of flips, the probability of gettig o SNAP is /, ad so the probability of o SNAP o both trials is (/) = /, ad so the probability of at least oe SNAP is (/) = /. Ad that's Jeie s formula. Now what makes this differet from the card problem? Well, it's that successive tosses of a coi are "idepedet" i the sese that what happes o the first toss has o effect o the possibilities for the ext. But ow back to the origial problem. The idea was ow out there that we might try usig smaller decks, ad we pursued this hopig maybe a patter might be foud as we icreased the deck size. Suppose we deote by P() the probability of a SNAP with a deck size of. Let's try to calculate the first few P(). We already have P() = ad P() = /, as oted above. A deck size of. A few momets were eeded for P(), ad there were a couple of differet approaches. Oe, which was quite istructive, was to simply write dow all possible pairs of decks ad cout up the umber of SNAPs. If we call the cards of the first deck A, B ad C, i order, the the 6 (=!) possibilities for the secod deck are displayed as the six colums at the right. The checked cases give SNAPs, for a SNAP probability of /6 = /. The ice thig about this approach is that it clearly displays the probability as the proportio of successes amog all the equally likely possibilities. While we're at it, ca you see how to modify the -card game to make Jeie s formula correct? Somehow, you have to make successive plays (of a pair of cards) "idepedet", ad have the same probability of SNAP at each play. The aswer is that after each play, you should gather up the two cards that were played ad shuffle both decks. The, at each play, the probability of o SNAP is /, ad the above calculatio holds if you do this times. A iterestig ad importat digressio! first secod A A A B B C C B B C A C A B C C B C A B A sap? Ay drawbacks to this approach? well it might get uwieldy for large decks. For example, for a deck of size, there are! = colums which you could still list i a couple of miutes but for a -card Sap //007
deck, there are! ad that s about 0 68. That s a lot whe you cosider that a computer which looked at a millio colums per secod ruig sice the begiig of the uiverse would have covered less tha 0 colums. The other kid of argumet I got was a aalysis of cases. Either there's a SNAP right away (p = /) or ot (p = /). I the secod case, the top cards are differet, ad if you look at how the remaiig two pairs of cards ca sit, there will be a SNAP with probability /. This was a importat approach for the purposes of geeralizig to bigger decks, ad so we worked a while o the presetatio. The scheme I ecouraged was the use of a tree. P( ) ( ) 0 = + + = P() CC CA 0 I this diagram, braches divergig from a commo poit represet differet possibilities, ad they are labeled with the probability of that alterative. The umbers at the extreme right are the SNAP probabilities of the differet routes. I the first pair, we argue that either the first two cards are the same, i which case we call them, or they are differet, i which case we call them. I the latter case, we the cosider the two possibilities for how the rest of the deck might look, ad record the SNAP probability i each case. Notice that we have tried to be ecoomical i the umbers of braches, with the result that the way we use the symbols A, B ad C is differet from before, but more powerful. With this otatioal scheme, we do t keep track of the order of the cards i a deck (that's ot what s importat), but just what's opposite what. So B desigates the card i deck- opposite A i deck-, whatever that happes to be (differet from A). Ad the the two boxes o the right describe the cases i which the deck- A is or is ot opposite the deck- B. A deck size of. Let s try the same diagram for P(). A good exercise for the class to see how well they uderstad what is shapig up to be a powerful method of aalysis. P( ) = + + = ( ) 8 P() The remaiig diagrams have ot bee draw for the calculatio of the ½ s i the last two cases, but they are easy eough to produce or eve to do i your head. Sap //007
A deck size of. P( ) ( ) = + + = 9 0 P() Agai the last part of the argumet is ot detailed i the diagram, but oly the aswer is give. (We certaily ca t cotiue to record all the braches!) Actually, a few studets were havig a bit of trouble followig the argumet, ad we took a few momets to expad the lower braches o the P() tree just to see that the probabilities o the right were actually proportios of successes amog the differet possibilities. How far are we goig to go like this? Should we work out P(6), P(7), etc.? I fact, it was clear to everyoe that this approach was goig to get pretty tough pretty soo, ad so we'd better fid some patters. Is there a patter emergig i the P() umbers? Well, o oe was able to see oe. [Except, aother time I did this, a studet did fid quite a remarkable patter. See problem.] P() / / /8 However, there did seem to be some patters i the argumets themselves. At ay rate, a umber of studets remarked that whe ivestigatig, for example, the case =, some of the argumets used were familiar they had already occurred earlier. Is there some way to get a partial "recursio" out of this? Oe observatio that was made immediately is that, for the P() argumet, whe we get to, the rest of the deck is really a -card deck, ad the SNAP probability is P(). So the / i the P() diagram is really P(). That's rather ice ad we iserted that ito the P() tree. P() P() Ca we do somethig similar with the lower part of the diagram? I this case we have. What ca the rest of the deck look like? What is that ½? Have we see it before? We wet over the argumet agai, sesig real echos of previous argumets, but ot quite able to put our figer o aythig. Sap //007
Ad the a had wet up i the back of the room (that woderful had that adds ew meaig to the phrase ledig a had ). If you forget about B, you really have a -deck, with a AC o top. That is: AC C? is equivalet to C? D? D? E? E? Ad the set-up o the right has occurred before it s right up i P(). Ideed it has: it s the SNAP probability for the lower arm. That is, if we call this probability Q, the Q occurs both i P() ad i P(), as follows. This is a woderful observatio. It idetifies a isomorphism (a word that literally meas same structure ) betwee a brach of the P() tree ad a brach of the P() tree. Ad that allows us to complete our recursio. Eve so fiishig the argumet off, that is, makig the Q substitutio, is a sophisticated techical maoeuvre. P( ) = + () ( Q) P() Q P() = + P() + Q ( ) P() P() Q Of course we kow that Q is equal to /, but that s ot the poit the poit is that we have a "coectio" betwee the P() tree ad the P() tree, ad that's importat because our strategy is to fid some way of workig up from small decks to large decks. If we elimiate Q from the two equatios, we should get a formula for P() i terms of P() ad P(). Let s do it. Solve the P() equatio for Q: () Q = P P( ) = + P() + Q P() = + P () + P ( ) = P() + P() This is a eormous discovery ad it has come Wham! right out of the blue. Not oly is it a perfectly woderful formula, its compellig form covices us that if there s ay justice i this uiverse, it should be geerally true that is, the correspodig formula should hold for P(6), P(7), etc. givig us a way of easily geeratig higher P values. Sap //007
This remarkable formula displays P() as a "weighted average" of P() ad P() with weights / ad /. Geometrically, if we thik of the real lie, this meas that P() is betwee P() ad P(), ad divides the distace betwee them i the ratio of to, beig closer to P() (sice it has the bigger weight). P() P() P() P ( ) = P() + P() A recursive formula for P() simple, elegat ad altogether surprisig. I fact, the same argumet works quite geerally ad gives us the recursio: P ( ) = P( ) + P( ) Agai, P() is a weighted average of the two previous P values, but the weights deped o as icreases, P() gets relatively closer to P( ). If we track a few successive P values o the real lie, we see that the fact that each P() is betwee the two previous values forces the P() to oscillate.. P() P(7) P(6) P() P() With this behaviour, the P() would also seem to have to approach some limitig value. I woder what that is. What s ext? Well, we could use the above formula to calculate quite easily a lot more values of P(). I particular, we could use a spreadsheet to calculate P() i o time. I fact, oe studet had a programmable calculator, ad programmed the routie. His program calculated ad displayed each P() usig the previous two P-values which he stored each time. Whe he ra it, he oticed a iterestig thig aroud =, his display stopped chagig. It appeared that from = o, all the P() were the same to 9 decimal digits ad all equal to: P() = 0.609 ( > ). A useful corollary of this is that the game of SNAP with a -card deck is o differet from the -card game, provided all you care about is whether or ot you get a SNAP, ad provided you're ot sesitive to the 0th decimal place! This recursio allowed us to easily exted our table of values for P() ad we added a few etries. See ay patters yet? P() / / /8 9/0 6 9/ 7 /80 Sap //007 6
At last someoe tried successive differeces P() P( ) (oe of the stadard tools for ay "what's the ext term i this sequece" questio). We got:, 6,, 0, 70, 00. See this before? It s the sequece /! (Eureka!) with alteratig sigs. P() / / /8 9/0 6 9/ 7 /80!,!,!,!, 6!, 7!,... Now this allows us to actually write a formula for P(). We start with P() =, ad the get each P() from the previous oe by addig the appropriate differece. P() = P() =! P() = +!! P() = +!!! ad i geeral P() = + K ±!!!!. That was quite a jourey. I fact, this is a hard problem, but I fid that eve studets i grade 9 ad 0 ca gai a lot from it. It is ot ackowledged early eough that at the early stages i mathematical learig, it's importat just to see structures "appear" i all their power ad mystery, ad produce aswers to your problems, eve whe you do't quite uderstad what's happeig. It ca be verified directly that this formula for P() solves the recursio. [A ice thig about solvig equatios: we may ot kow how to do it, but ay time we maage, somehow, to get a cadidate, we ca always fid out whether it's a solutio by pluggig it i!] I particular the formula gives, for =, a exact expressio for our stadard-deck SNAP probability P(). Sap //007 7
Problems.(a) Cosider a deck of cards, umbered to ad J (for joker). Now play SNAP with two such decks, with the rule that if the two jokers go dow together this does ot cout as a sap. Calculate the sap probability P*(). (b) Cosider a deck of cards, umbered to 0 ad two idetical jokers J ad J. Now play SNAP with two such decks, with the rule that if ay two jokers go dow together this does ot cout as a sap. Calculate the sap probability P**(). (c) Cosider a deck of cards, umbered to 0 ad two idetical jokers J ad J. Now play SNAP with two such decks, with the rule that if ay two jokers go dow together this will cout as a sap. Calculate the sap probability R().. Last time I did this problem, oe of the studets foud a remarkable patter. For each deck size, he tabulated the umber M() of cases (out of!) i which there was o SNAP. For example, for =, out of the 6 possible orderigs of the secod deck, are SNAPs, givig M() = 6 =. He the oticed that if you add two successive etries i the M colum, ad multiply by the higher value, you get the ext etry i the M colum. For example: (0+) = (+) = 9 (+9) =, etc. He also observed that this was ot such a strage "rule". It also worked for factorials. This seems to me like a good startig poit for a aalysis of the problem. M() 0 9 6 6! 6 0 6 70. Suppose that we are iterested ot i the probability of gettig a SNAP, but i the umber of SNAPs. That is, if we get a SNAP, we do t pick up the deck ad start agai, but we cotiue ad keep track of the umber of SNAPs we get by goig to the ed of the deck. If we do this agai ad agai, what is the average umber of SNAPs per deck? [There s a elegat way to thik about this problem. A useful idea is foud i Darts.] Sap //007 8
. A crucial stage i our developmet above was the discovery of the woderful recursio: P( ) = P( - ) + P( ). We could have fiished up at this poit by directly solvig this recursio, but we did t kow how. It s worth otig that we have ecoutered secod-order recursios before ad we foud a way to solve them. For example, i Biet Ex., we solved the recursio t = t + t. Here the coefficiets ( ad ) are costats, idepedet of, but i the P-recursio this is ot the case, ad our Biet method wo t work. What we did do, is look at the differeces Q() = P() P( ) ad we foud a simple arithmetic patter i these. Well, that gives me a idea for how we might have solved the P-recursio i the first place: defie the differeces Q() ad try to obtai a recursio for them. I guess there s a chace it might tur out to be a bit simpler tha the P-recursio. Follow this idea up. What was it about the P-recursio that made this approach work? Ca you formulate a geeral result about how to solve certai kids of recursios?.(a) The formula P() = + +... ±.!!!! might rig a bell for ayoe who has see the famous ifiite series expasio for the expoetial fuctio: x x x e x = + x + + + +...!!! x Now the series for P() is fiite, while that for e goes o forever, but use the fact that for > the P() are all the same to 9 decimal places to fid a simple formula for P() i terms of the umber e accurate to 9 decimal places. Use your calculator to check your aswer. (b) (For those who kow a bit about ifiite series) I fact the accuracy of the approximatio of (a) is cosiderably better tha 9 decimal places. How good is it? [Hit: the series for P() is alteratig.] (c) Let s go back to Jeie s (ivalid) argumet that P() = (/) = 0.66. Her aswer is exceedigly close to the correct aswer P() = 0.6 (everythig to decimal places). [I a sese that suggests that with a large deck successive cards are almost idepedet.] Ca we uderstad why these should be so close? [Hit. The trick here is to use aother famous limit formula for e: e = lim + Actually, we eed the more geeral versio: What does this give us for /e?] r e = lim + r Sap //007 9