BIRTHDAY PARADOX –

A SIMULATION OF SHARED BIRTHDAY EXPERIMENTS

Stephen Hogan (50217631)
Postgraduate Diploma in IT (Evening)
Dublin City University School of Computing
hogans2@mail.dcu.ie

Abstract  Being one of the most well-known and famous problems in 2. BACKGROUND
probability1, the question is asked: “How many randomly chosen people
are needed to achieve at least a 50% probability that some pair will both Comment [JM4]: This could be
have been born on the same day?” Since the chance of any two persons Mathematical Model compressed by simply giving a single
having the same birthday is remote, many of us would expect this number equation and pointing the reader to a
One of the basic rules of probability: the sum of the probability that an reference whre more detail is given.
to be rather large. However, it turns out that this is not the case, and
event will happen and the probability that the even will not happen is
hence the paradox.
always 1. In other words, the chance that anything might or might not
happen is always 100%.
A simulation of empirical testing and results was conducted to simulate
multiple trials, where people of a given group size have their birthdays
If we can work out the probability that no two people will have the same
compared. The probability is consistently monitored and established as
birthday, we can use this rule to find the probability that two people will
the number of successful experiments as a proportion of the total number
share a birthday:
of experiments performed.

As the theoretical value is already known (23), it was also the goal-driving P(event happens) + P(event does not happen) = 1
→P(two people share birthdays) + P(no two people share birthdays) = 1
result for the algorithm being implemented in Java, and happily, was
achieved.
 P(two people share birthdays) = 1 – P(no two people share birthdays) Comment [JM5]: Mixed font size.
Comment [JM1]: Keep it formal and to
The formula for the probability that n people have different birthdays
the point.
(month and day) is3:
1. INTRODUCTION 365
Premise born in 19382: In a room of just 23 people, there is a 50% 365  n! * 365n (1)
Comment [JM2]: Use a reference rather
probability of two of these people sharing the same birthday, (ignoring than a footnote.
years of birth). In a room of 75 people, there is a 99.9% chance of two Therefore, the probability that at least two of them share the same birthday
people with matching birthdays. This is one particular case of exponential is:
(Saliusian) sets, where duplicates are allowed. Exponents are not intuitive, 365 Comment [JM3]: A reference would be
1 (2)
and thus why our linear-thinking leads us to an incorrect estimation! 365  n! * 365 n welcome here.

While theoretical mathematical models and proofs have been derived in

previous works outside the scope of this paper, the object of this paper is
not to put the formulae into action; moreover the objective of this paper is
to highlight a proof by example; i.e. that a simulation of birthdates for a
group of people is analysed for this probability result, based on the
aforementioned premise.
Having (2) graphed in Figure 1 it is clearly seen where, at the probability
of 50%, cross-referencing it with the number of people reveals a value of
23:

For the following two sections, Background and Method, to be

presented here, both share the following assumptions:

 That there are only 365 days in a year, i.e. thus ignoring leap years.
This also results in ignoring the suspension of leap day on years
divisible by 100 that are also divisible by 400.
 Birth years are ignored.
 People’s birthdays are equally distributed throughout the year; (i.e.
influencing elements such as seasonality are not factored in).
Obviously in real-life, birthday distributions are not uniform, i.e. not
all dates are equally likely.
 The date of a person’s birthday does not affect the date of another
person’ birthday, i.e. twins, triplets, etc.
Figure 1: A graph showing the approximate probability of at least two
people sharing a birthday amongst a certain number of people 4.

1
This is not a paradox in the literal sense – it just highlights the fact that people
expect the value to be much larger. 3
As Dr Math FAQ – The Birthday Problem
2
American Mathematical Monthly in 1938 in Zoe Emily Schnabel's The estimation (http://mathforum.org/dr.math/faq/faq.birthdayprob.html)
of the total fish population of a lake, under the name of capture-recapture statistics. 4
Wikipedia - Birthday Problem (http://en.wikipedia.org/wiki/Birthday_paradox)
 3. METHOD
Programming Methodology
The simulation was written in the Java language 5. A text file that lists
multiple trials with the following parameters serves as input to the
The last record in this table is graphed in Figure 2. Preparing graphs for
all records processed in this table (Appendix 4) reveals, interestingly, that
time performance dips in proportion to the curve of probability when
tending to 23 people, irrespective of the number of trials:
Simulation 8
0.60000 25000

program, (defaults outlined here are geared to solving the problem in

question): 0.50000
20000

 Number of matches to be checked (default: K = 2)


0.40000
Number of trials (various >> values) 15000

 Probability

Time (ms)
Starting group size (default: N = 2) 0.30000

 Group size increment (default: 1) 10000

 Terminating probability (default: 0.5) 0.20000

5000
Assumptions: 0.10000

 The group size will never be greater than 1,000.

 In the case that the starting value of N is less than K, you should 0.00000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
0

start the simulation with N = K. The reason is simple: How do No. People

Probability Time (ms)

you possibly find three (i.e. K) matches in a group of two (i.e. N)
persons?
Beginning with group size of N = 2 people, we initialise an array with the
random birthdays of N = 2 people; (the random number generator is being
seeded with the current time). We compare every pair wise (number of
matches K = 2) combination of people in the group of N = 2 and check the
existence of any two persons having the same birthday.
This will be repeated number of trials times with different groups of two
people. If the average occurrence of two persons having the same birthday
in these one thousand trials exceeds 0.5 (i.e. the probability P), the
simulation terminates. Otherwise, N is incremented by group size
increment = 1, and the entire simulation of one thousand trials is repeated
with randomized groups of (starting group size = 2) + (group size
increment = 1) people.
The flexibility in reading in values from a file that control the execution of
the algorithm allows us to evaluate numbers of people for various
probabilities and/or enumerate possible combinations of more than two
persons, differing numbers of trials and matches, and check for shared
birthdays, for example. A review of the Java source code in Appendix 2
should reveal other variations.
Comment [JM9]: You need to explain
Figure 2: Simulation 8 what Simulation 8 is.
5. CONCLUSIONS & RECOMMENDATIONS
This research reports on a simulated empirical study of the Birthday
Paradox. The findings suggest that there is a strong similarity between the
theoretical and (simulated) actual probabilities. Specifically, that for any
group size or number of trials, to achieve at least a 50% probability in
solving the problem, we would need at least 23 people in a room for
comparison (with previously unknown birthdays).
The input file allows for variations on the number of people > pairs as well
as the group increment size to be > 1, as well as other terminating
probabilities.
A further recommendation would be to refine the sorting algorithm even
further, or adopt a faster mechanism of sorting, especially for large N and
K. Parallelisation of Quicksort, for example, would be ideal, as
synchronisation is not a requirement. Java Threading would be an
approach for this.

For each trial, a number of random birthdays are generated and placed into Another approach to solving this problem would be to base it on collisions
an array; (here, we use the Julian Date format, 1…365). These birthdays – by tracking as each person enters the room and checking to see if there is
are sorted and then iterated through to find the same values in consecutive a match with any other person. An array of 365 elements would only be
elements in the array, denoting a success. Once the trials have completed needed, and a random date only generated for each person until either the
running, the probability is evaluated as6: entire group size is exhausted or a match has been found. The author of
this paper decided against this approach after initially selecting it, as it Comment [JM10]: We
currProbability = numSameBirthday / numTrials would not be possible to measure time performance as fluidly.
Comment [JM6]: Why not use algrbraic
notation as in (1) and (2). Also: This eqn is
not numbered.
4. RESULTS & DISCUSSION 6. REFERENCES
With the availability of having an input file, multiple case scenarios can be [1] Birthday Paradox Wikipedia.com
generated. Table 1 is an example of sample data was available on the (http://en.wikipedia.org/wiki/Birthday_paradox)
input file, (as per aforementioned format in Section 3):
2 10000 2 1 0.5 [2] CS1101C Lab 3 – Birthday Paradox National University of Singapore,
2 20000 2 1 0.5 School of Computing
2 30000 2 1 0.5 (http://www.comp.nus.edu.sg/~cs1101cl/labs_sem2_0405/lab3/oddweek/)
2 50000 2 1 0.5
2 700000 2 1 0.5
2 1000000 2 1 0.5 [3] How to Generate Random numbers About.com
2 2000000 2 1 0.5 (http://java.about.com/od/javautil/a/randomnumbers.htm)
2 5000000 2 1 0.5
[4] Quick Sort Implementation with median-of-three partitioning and Comment [JM7]: Explain the entries in
Table 1: Input File sample data. cutoff for small arrays Java-Tips.org the table.
(http://www.java-tips.org/java-se-tips/java.lang/quick-sort- Comment [JM8]: Why capitalise?
implementation-with-median-of-three-partitioning-and-cutoff-for-small-
5
Adapted from [2] a.html)
http://www.comp.nus.edu.sg/~cs1101cl/labs_sem2_0405/lab3/oddweek/paradox.c
6
See Appendix 1 – Pseudocode.
APPENDIX 1 – PSEUDOCODE

SET variables numTrials = any large number

currGroupSize = 2
currProbability = 0.0
terminatingProbability = 0.5

DO
{
SET variable numSameBirthday = 0

DO WHILE currProbability <= terminatingProbability

{

DO FOR EACH trial FROM 1 TO numTrials

{
SET RANDOM number FOR EACH ELEMENT IN birthday[] UNTIL birthday[currGroupSize]

Sort birthday[] into ascending order

Check for match between consecutive elements: IF TRUE THEN numSameBirthday = numSameBirthday + 1 Comment [JM11]: Complexity of th
could have been discussed in the paper.
} END FOR

currProbability = numSameBirthday / numTrials

currGroupSize = currGroupSize + groupIncrement

} END WHILE

} END DO LOOP
APPENDIX 2 – SOURCE CODE

BirthdaySimulation.java

Double-Click to open the entire embedded document.

Birthday.java

Double-Click to open the entire embedded document.

QuickSort.java

Double-Click to open the entire embedded document.

APPENDIX 3 – JAVADOC

BirthdaySimulation.java

Double-Click to open the entire embedded document.

Birthday.java

Double-Click to open the entire embedded document.

QuickSort.java

Double-Click to open the entire embedded document.

APPENDIX 4 – CHARTING RESULTS

Simulation 1

0.60000 35

30
0.50000

25
0.40000

20
Probability

Time (ms)
0.30000

15

0.20000
10

0.10000
5

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

Simulation 2

0.60000 80

70
0.50000

60

0.40000
50
Probability

Time (ms)

0.30000 40

30
0.20000

20

0.10000
10

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

 Simulation 3

0.60000 120

0.50000 100

0.40000 80
Probability

Time (ms)
0.30000 60

0.20000 40

0.10000 20

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

Simulation 4

0.60000 180

160
0.50000
140

0.40000 120
Probability

Time (ms)

100
0.30000
80

0.20000 60

40
0.10000
20

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

 Simulation 5

0.60000 3000

0.50000 2500

0.40000 2000
Probability

Time (ms)
0.30000 1500

0.20000 1000

0.10000 500

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

Simulation 6

0.60000 6000

0.50000 5000

0.40000 4000
Probability

Time (ms)

0.30000 3000

0.20000 2000

0.10000 1000

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

 Simulation 7

0.60000 9000

8000
0.50000
7000

0.40000 6000
Probability

Time (ms)
5000
0.30000
4000

0.20000 3000

2000
0.10000
1000

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)

Simulation 8

0.60000 25000

0.50000
20000

0.40000

15000
Probability

Time (ms)

0.30000

10000

0.20000

5000
0.10000

0.00000 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No. People

Probability Time (ms)