thanks again your effort. The hypergeometric series introduces another point of view and I gave it a try. Unfortunately I am basically stuck with the same problem.
First of all, the hypergeometric series reproduces all of the probabilities from my previous post. Yet, the way downthesun01 used the series does not give the probabilities to tie, as can easily be seen at the first tie. Instead, is the probability to tie with a specific pair, e.g. aces [AA]. Just multiply this by the number of ways to choose a specific card, i.e. , and you've got the probability for the first tie, that is [xx].
Going on in this fashion reconfirms the probabilites already calculated in the "calculating probabilities" approach.
Unfortunately, although the hypergeometric series is used to calculate the probabilities for [xxyyxxyy] etc., the tree scheme
remains unchanged. Hence, Prob([xxyyxxyy]) = Prob([xxyyyyxx]) = Prob([xxxxyyyy]) occurs again three times and the prefactors in the "calculating probabilities" approach remain unaltered.
Is this tree scheme correct, i.e. do I really have to account for product (c) six times? Or is my initial "counting combinations" approach correct and there's an error I just don't see with "calculating probabilities" (with or without employing the hypergeometric series).
Unfortunately, both approaches appear rather convicing to me.
Any ideas on what went wrong?
Thanks again for helping,
@undefined: Your suggestion to try a reduced deck of cards is surely very promising in order to get a more detailed view on the combinatorics. And you're right: A smaller deck renders a numerical treatment of the problem possible. It ought to be easy to implement this problem numerically and thereby decide whether the "calculating probabilities" approach is correct or "counting combination" does the job (or both fail). Yet, to put it in the words of Eugene Wigner: 'It is nice to know that the computer understands the problem. But I would like to understand it too.'