Before probability was established as a branch in Math or Science, how did people calculate (or estimate) the likelihood (aka P) of some events, say, the likelihood of getting a head in throwing a coin?
I guess the most direct way was to throw a coin a thousand times to discover something called likelihood, chances or trends. This puzzle begs you to throw the coins by computer to discover an accurate-enough estimation of likelihood. It is primitive but much faster than your high-precision recursion.
1 Like
Got it, as you said, not as precise, but good enough.
Thanks.
Sometimes the dumbest solution is the best. Random generator, big numbers, simple code: brute force withouth any math.
1 Like
This was a fun one. I managed to get ~4.5 mill iterations out of a naive rust implementation. It would be interesting to know if anybody has solved this mathematically rather than through brute force.
1 Like
How did you get 92% at test 1?
1 Like
Have you read the discussion above?
I tried to do the math but am having difficulty understanding why m=6 n=7 leads to ~92%.
What would the probability be if m=2 and n=3?
Update: Never mind. I was just too sleepy.
I had fun finding the minimal number of simulations to bruteforce all tests and validators with a simple rand() function and a round() on the output.
Spoiler alert
Summary
It’s 72026, and the limiting test is test02
Nice puzzle Westicles, as usual
2 Likes
We must use brute force method?
Yes you may.
But execution time is too long. So that craches.
Thus, instead of 10¹⁶ loops, do just 10⁶ loops.
You can also solve it with either clever math or recursion.
I remember that back in the days when I was at the university, we never really studied Monte Carlo methods. Neither Las Vegas methods. I distinctly remember reading about the two, but hardly using them in practice. Okay, so we have monte carlo in this puzzle, and in ultimate tic tac toe. How about some sort of Las Vegas algorithm/problem?
My final result is a fraction, and i have to round it to get an integer value.
Some one else has different results depending on the language with the brute force but with the same algorithm ?
I passed in Python, but incorrect values in Swift
Do you get incorrect values in IDE or with validators only?
If in IDE, what values do you get in Swift? Are there any major differences in the logic or the parameters between your Python code and your Swift code?
Why? Isn’t there a formula to calculate this problem with O(1)?
Why is my first thought approach wrong? For example if you have m=6 and n_spins=7.
In the first spin, your propability to not choose one of the first five numbers again is 1.0 then it is (37/38),(36/38),(35/38),(34/38),(33/38), and in the seventh spin it stays (33/38).
I tried to multiply everything with each other, but the result was not 92% but 57%.