Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iPod Which letters/digits they use in Pepsi cap codes
- Thread starter Doctor Q
- Start date
- Sort by reaction score
vieoray said:93 so far
whoa!! wanna share?
i wish i was that lucky, btw when do you have to have your codes entered by?
I used to think that the codes had to have a checksum built in to prevent people from guessing codes easily. For example, if 3 of the characters were computed from the other 7, then even if you picked 7 of the characters of a valid code, your chances of guessing the other 3 would be 1 in 29^3, i.e., chances of 1 in 24,389, so you'd take an average of 12,194 guesses before you'd get one right. The poor odds are the deterrent.
However, I now think that a checksum is not necessary, for two reasons, both of which show that they can verify codes without worrying about people guessing them.
Reason #1: The codespace (number of possible codes) is 29^10, which is much larger than the number of codes they've actually used (200,000,000). If I did my logarithms right, your chances of guessing a random code even with no checksums are 1 in 2,103,536. Not likely.
Reason #2: If you put in a code, the server has to make two decisions: (1) is it valid? and (2) has it already been used? To handle (2), it must store information (some kind of table) to know which caps have been used. I believe that handling (2) will take care of (1) as well.
They wouldn't necessarily have to store a table of size 29^10 = 420,707,233,000,000 to do this. Here's a programming technique they might have used to prevent the table from being so huge: Suppose they created a one-to-one mapping between integers (1, 2, 3, etc.) and the character space (the 29^10 possible codes). On the server, they make a table of size 200,000,000 bits (that's only 24MB), initially all zero. When you enter a code, the reverse mapping is applied to the code to produce the integer. If it is 1 thru 200,000,000, it's valid. If not, it's invalid. Then the table is checked. For integer n, the nth bit is checked. If it is 0, it is set to 1 and you get your tune credit. If it is 1, you or somebody else has already used this code.
By the way, when the promotion is over, the number of 1's in the table is the number of tunes redeemed and the number of 0's is the number of caps distributed but never claimed. I'd sure like to know those numbers!
However, I now think that a checksum is not necessary, for two reasons, both of which show that they can verify codes without worrying about people guessing them.
Reason #1: The codespace (number of possible codes) is 29^10, which is much larger than the number of codes they've actually used (200,000,000). If I did my logarithms right, your chances of guessing a random code even with no checksums are 1 in 2,103,536. Not likely.
Reason #2: If you put in a code, the server has to make two decisions: (1) is it valid? and (2) has it already been used? To handle (2), it must store information (some kind of table) to know which caps have been used. I believe that handling (2) will take care of (1) as well.
They wouldn't necessarily have to store a table of size 29^10 = 420,707,233,000,000 to do this. Here's a programming technique they might have used to prevent the table from being so huge: Suppose they created a one-to-one mapping between integers (1, 2, 3, etc.) and the character space (the 29^10 possible codes). On the server, they make a table of size 200,000,000 bits (that's only 24MB), initially all zero. When you enter a code, the reverse mapping is applied to the code to produce the integer. If it is 1 thru 200,000,000, it's valid. If not, it's invalid. Then the table is checked. For integer n, the nth bit is checked. If it is 0, it is set to 1 and you get your tune credit. If it is 1, you or somebody else has already used this code.
By the way, when the promotion is over, the number of 1's in the table is the number of tunes redeemed and the number of 0's is the number of caps distributed but never claimed. I'd sure like to know those numbers!
A more likely implementation is as follows:
They generate the codes as random combinations of letters and digits, while filling in a hash table. The hashing function is much simpler to create than the one-to-one function I described in the previous post.
Each slot in the hash table holds a list of codes that hash to that slot. The bigger the hash table size, the more sparse it will be, with the fewest collisions and the shortest average list size. Each code has a used/unused bit, set to "unused" initially.
When you redeem a cap, the code is hashed to find the hash table slot. If the code is not in the list for that hash table slot, the code is invalid. If the code is marked "used", the code was previously used. Otherwise, it is changed from "unused" to "used" and you get your tune credit.
If stored efficiently, the table would be a percentage larger than the size of the codes, i.e., 10 x 200,000,000 bytes, or about 1.9GB. As with the previous implementations, no checksum is required to keep customers from easily guessing codes.
I wonder if they check the randomly generated codes to make sure they don't accidentally include profane or politically incorrect words? With random codes, this isn't very likely, but it's possible. The only word of 4 or more letters I've found in my codes so far is WILE.
They generate the codes as random combinations of letters and digits, while filling in a hash table. The hashing function is much simpler to create than the one-to-one function I described in the previous post.
Each slot in the hash table holds a list of codes that hash to that slot. The bigger the hash table size, the more sparse it will be, with the fewest collisions and the shortest average list size. Each code has a used/unused bit, set to "unused" initially.
When you redeem a cap, the code is hashed to find the hash table slot. If the code is not in the list for that hash table slot, the code is invalid. If the code is marked "used", the code was previously used. Otherwise, it is changed from "unused" to "used" and you get your tune credit.
If stored efficiently, the table would be a percentage larger than the size of the codes, i.e., 10 x 200,000,000 bytes, or about 1.9GB. As with the previous implementations, no checksum is required to keep customers from easily guessing codes.
I wonder if they check the randomly generated codes to make sure they don't accidentally include profane or politically incorrect words? With random codes, this isn't very likely, but it's possible. The only word of 4 or more letters I've found in my codes so far is WILE.
I'm surprised the Apple iTunes codes include vowels... the Microsoft product IDs (previously mentioned) don't include any vowels, zeroes (0/O), or ones (1/I), so there's no chance of any words (especially dirty words) showing up in any codes. Sure, it's unlikely to happen, but what happens if someone finds a code that includes a combination like "DIK" or worse?
PlaceofDis said:whoa!! wanna share?
there's a limit of 200 per user, so if i get that many i would be glad to share. the promotion ends april 30, but you have until about the end of may to use the codes (dont remember the exact date, i think may 23)
If they are American, they probably take great offense, claim it was done on purpose, start a blog about it, demand that the practice stop, insist that they be paid for their mental anguish, and appear on lots of talk shows to discuss it.clayjohanson said:Sure, it's unlikely to happen, but what happens if someone finds a code that includes a combination like "DIK" or worse?
I got one with an O today. I typed a D instead and it was accepted. That completes my test of each cap assignment.Doctor Q said:
I have shown that the Pepsi code rules are as follows:
There are 24 possible letters and 5 possible digits, for a total of 29 choices for each of the 10 characters.
No codes have 0 or D.
For an O, you can enter O or 0 or D.
No codes have 1.
For an I, you can enter I or 1.
No codes have 2.
For a Z, you can enter Z or 2 (but see note below).
No codes have 5.
For an S, you can enter S or 5.
No codes have 8.
For a B, you can enter B or 8.
No codes have U.
For a V, you can enter V or U.
No codes have 0 or D.
For an O, you can enter O or 0 or D.
No codes have 1.
For an I, you can enter I or 1.
No codes have 2.
For a Z, you can enter Z or 2 (but see note below).
No codes have 5.
For an S, you can enter S or 5.
No codes have 8.
For a B, you can enter B or 8.
No codes have U.
For a V, you can enter V or U.
Note: PlaceofDis remembers having to type "2" rather than "Z", which I can't explain, unless it was last year, not this year. I will keep watching for 2s and Zs. But the chances that 2s are valid and I have not gotten one are very slight.
Who wants to know the probabilities that you'll find letter Q in your iTunes Pepsi code?
If your favorite letter isn't Q, the probabilities are the same for YOUR favorite letter (unless your favorite letter is a D or a U, which they don't use). We will assume (since we can't tell) that all letters and digits are equally likely in each code position.
Probability of getting at least one Q: 29.6% (1 in 3.38)
Probability of getting exactly one Q: 25.1% (1 in 3.98)
Probability of getting exactly two Qs: 4.04% (1 in 24.8)
Probability of getting exactly three Qs: 0.39% (1 in 260)
Probability of getting exactly four Qs: 0.024% (1 in 4,157)
Probability of getting exactly five Qs: 0.0010% (1 in 97,004)
Probability of getting exactly six Qs: 0.000031% (1 in 3,259,332)
Probability of getting exactly seven Qs: 0.00000063% (1 in 159,707,253)
Probability of getting exactly eight Qs: 0.0000000084% (1 in 11,924,808,200)
Probability of getting exactly nine Qs: 0.000000000067% (1 in 1,502,530,000,000)
Probability of getting exactly ten Qs: 0.00000000000024% (1 in 420,707,000,000,000)
Bad news: 70.4% of the time (1 out of every 1.42 times) you will find no Q at all in your Pepsi code. I'm disappointed with such codes, but I reluctantly redeem them anyway.
Good news: Your probability of getting either no Qs, 1 Q, 2 Qs, 3Qs, 4 Qs, 5 Qs, 6 Qs, 7 Qs, 8 Qs, 9 Qs, or 10 Qs is 100%!
For those of you still reading, here is the formula:
Probability of getting n of a given letter =
If your favorite letter isn't Q, the probabilities are the same for YOUR favorite letter (unless your favorite letter is a D or a U, which they don't use). We will assume (since we can't tell) that all letters and digits are equally likely in each code position.
Probability of getting at least one Q: 29.6% (1 in 3.38)
Probability of getting exactly one Q: 25.1% (1 in 3.98)
Probability of getting exactly two Qs: 4.04% (1 in 24.8)
Probability of getting exactly three Qs: 0.39% (1 in 260)
Probability of getting exactly four Qs: 0.024% (1 in 4,157)
Probability of getting exactly five Qs: 0.0010% (1 in 97,004)
Probability of getting exactly six Qs: 0.000031% (1 in 3,259,332)
Probability of getting exactly seven Qs: 0.00000063% (1 in 159,707,253)
Probability of getting exactly eight Qs: 0.0000000084% (1 in 11,924,808,200)
Probability of getting exactly nine Qs: 0.000000000067% (1 in 1,502,530,000,000)
Probability of getting exactly ten Qs: 0.00000000000024% (1 in 420,707,000,000,000)
Bad news: 70.4% of the time (1 out of every 1.42 times) you will find no Q at all in your Pepsi code. I'm disappointed with such codes, but I reluctantly redeem them anyway. Good news: Your probability of getting either no Qs, 1 Q, 2 Qs, 3Qs, 4 Qs, 5 Qs, 6 Qs, 7 Qs, 8 Qs, 9 Qs, or 10 Qs is 100%!For those of you still reading, here is the formula:
Probability of getting n of a given letter =
( 28 ^ ( 10 - n ) ) x 10!
-------------------------------
( 29 ^ 10 ) x n! x ( 10 - n )!
-------------------------------
( 29 ^ 10 ) x n! x ( 10 - n )!
I'm not a big pepsi drinker. But I STILL have not seen any iTunes bottles in NC. Kinda weird.
I did see a few last year, and bought 3 or 4. No winners, though!
I did see a few last year, and bought 3 or 4. No winners, though!
You are correct. Thanks. I said the chances were "1 in (29/36)^(64*10)" when I meant the chance is (29/36)^(64*10). I'll fix my post.telecomm said: