Talk:Birthday problem

"Near matches" - careless comment?

It is very careless to say that

"Thus in a family with six members, it is more likely than not that two members will have a birthday within a week of each other."

While i realise that it's tempting to make the group of six people a family, birthdays within a family are generally far from independent, especially if siblings are included!

Given the article it belongs to, i think the statement is out of place.

Good point. Fixed. Thanks. --Keeves 18:33, 9 August 2006 (UTC)[reply]

Glad to see that - this was my first (which is why i also forgot to mention my name) teeny-weeny contribution to Wikipedia. Thanks! --Rileen, 11 August 2006

29 February

It makes the article significantly more complex to take into account 29 February, so most of it doesn't — except for bits of the first paragraph. I think the article should simply state early on that 29 February will be completely ignored, and then it should abide by that.

Does anyone object to this?

Ruakh 17:09, 13 August 2006 (UTC)[reply]

I had thought of that exact idea yesterday, and I'm glad you suggested it. I have now added such a paragraph, and I hope it will be noticable enough to bring this back-and-forth to an end. --Keeves 21:32, 13 August 2006 (UTC)[reply]

Hmm. Your paragraph is very clear, but I worry that it might be a bit much; after all, it's not really the central point of the article, but really just a caveat clarifying that the article is about an abstract mathematical concept and does not necessarily apply perfectly to real life. It seems like a single sentence could conceivably suffice. (Further, it's not true that "it is just as likely that a randomly-chosen person's birthday will be January 21 or October 5 or almost any other day of the calendar"; different times of year actually have fairly different birth rates.) Ruakh 03:12, 14 August 2006 (UTC)[reply]

A footnote should be more then sufficent to account for the leapyear birthdays and just have a further explaination thereof. —The preceding unsigned comment was added by 12.163.97.74 (talk • contribs).

Mystery!

"23"! --nlitement ^[talk] 13:37, 30 September 2006 (UTC)[reply]

Approximation based on Taylor Series expansion

Isn't the expression obtained for p_bar(n) =approx= 1*e^-1/356*e^-2/365*...*e^-(n-1)/365 in the "Approximation" subsection based on the inequality "(1-x) < (e^-x)"? It doesn't seem to be based on the Taylor Series expansion of the exponential function; instead, it directly uses the exponential function.

But exp(-x) = 1 - x + x^2/2 - ... IS the Taylor expansion of exp(-x). Cut the expansion off after the term in x, and you get exp(-x) = 1-x. You can see that 1-x < exp(-x), by looking at the quadratic term of the Taylor expansion (the Taylor expansion is an alternating series). So you are basically saying the same thing, but the article actually shows why the inequality holds. —The preceding unsigned comment was added by 134.58.253.131 (talk • contribs) 11:30, 12 February 2007 (UTC).[reply]

Near matches?

Can we either cite or insert the math for the "near match" birthdays? The information is stated without proof. arctic 00:28, 27 November 2006 (UTC)[reply]

You're right to be concerned; I just wrote a quick Perl script to investigate this probabilistically, and it seems like the correct values for the table would be:

within k days	# people required
0	23
1	14
2	11
3	9
4	8
5	8 ← not 7, as the page currently has
7	7 ← not 6, as the page currently has

(Note: that was only probabilistic, but I used some basic techniques to ensure accurate results, so I'm fairly confident those are the correct values. As you say, though, a source or mathematical justification is quite necessary here. BTW, lest anyone be concerned that my random number generator might be biased — that's a valid concern, and it might well be, but if that were affecting the results, you'd typically expect greater synchronicity, hence lower values for the number of people necessary to ensure a 50% probability of a near match. The only bias that would produce higher values is a bias against synchronicity; that is, if the generator has a greater-than-random tendency against yielding recently-yielded numbers. I'll run some tests to ensure that that's not the case here, then comment back.)

Ruakh 01:49, 27 November 2006 (UTC)[reply]

Okay, I ran some tests, and it doesn't look like my random number generator has any bias against synchronicity. So, I think the table in the article is wrong. Ruakh 02:11, 27 November 2006 (UTC)[reply]

Collision counting

This was useful to me testing a password generation programme, and I couldn't find anywhere else in Wikipedia that gave this information. The hash collision article could perhaps link directly to this section.

I suggest that the section's usefulness would be improved by the addition that for 1 << n << d, as is typical, the formula reduces to $n^{2}/2d$ .

Also, knowing the standard deviation would be useful, as I'd like to assess how reasonable my observed number of collisions is. Jlittlenz 05:07, 8 December 2006 (UTC)[reply]

Forward vs. reverse?

Is there any reason for the notion that the "birthday problem" is computing p given n, while the "reverse birthday problem" is computing n given p (as implied in #Reverse problem)? Insofar as the two are separate problems, it seems to me that the ordinary birthday problem is computing the minimal n such that p > ½, so the "reverse birthday problem" would be computing p given n. —Ruakh_TALK 16:23, 8 December 2006 (UTC)[reply]

Archive