Some comments (all grouped together; sorry if this messes with the threaded view):
Edmund wrote:it is a much stricter margin indeed, but I would have imagined the closer you approach the final value the smaller the difference should become. More like in the following sketch:
There was indeed a bug.
Here's a fixed version. If you clamp the cutoffs to zero, the max cutoffs at each round now match Joseph Ciarrochi's numbers. (I also don't know when roundoff starts to kill the calculation, but the order of operations makes me think it would take quite a while.)
mcostalba wrote:Yes, it is interesting, but I would think you need to validate your program with real data.
For instance simulating a match using rand(), like: [...]
And verify that calculated probabilities corresponds to the one measured through simulated matches.
The code must be verified independently, and that's a good way. But in fact my code is just a continuous version of that simulation: it just counts the percentage of players with each score, as they play simulated games.
Nice work. I agree that a multiple precision library would help (esp. if it has log-of-factorial or log-of-gamma-function built in). You can also be smarter with the computations. You can build a table of this f(w,d,l) recursively:
Code: Select all
f(w+1,d,l) = f(w,d,l) * p_win * (w+1+d+l) / (w+1)
f(w,d+1,l) = f(w,d,l) * p_draw * (w+d+1+l) / (d+1)
f(w,d,l+1) = f(w,d,l) * p_loss * (w+d+l+1) / (l+1)
This way you won't ever overflow.
BTW, what's windows.h doing in your code?
mcostalba wrote:An easier way, for people that is not able to produce the needed statistical formula (almost everybody in this forum I would guess
, perhaps only Rémi Coulom has the theoretical background to be able to write some formulas) is to use a game simulator and plot the corresponding table. Also this is not trivial because you have to ask the correct questions to your simulator.
The simulator is not less powerful than a formula, if you (1) apply it to the probability density rather than one simulated player at a time and (2) don't write buggy code. Of course #2 means I don't have a chance.