Talk:Monty Hall problem

Haskel error on codepad?

I don't know Haskel but following the section header link, I tried to run it on [codepad], unfortunately it gave errors but I don't think I'm qualified to judge if they are true errors or something to do with the version of Haskel used on Codepad etc. Could someone comment and maybe fix things if there is an error? Thanks.

P.S. The error was:

  Error occurred
  ERROR line 26 - Type error in application
  *** Expression     : cars trials True g
  *** Term           : trials
  *** Type           : Integer
  *** Does not match : Int

--Paddy3118 22:10, 10 August 2008 (UTC)

My mistake. I wrote that program; the problem was that I used the Haskell implementation GHC, which allowed the literal "10000" to be an Int, and Codepad uses Hugs, which apparently interprets all literal integers as Integers by default. I believe the dreaded monomorphism restriction is to blame. Anyway, I added an explicit type signature, so the program now works with Hugs. Underscore 15:24, 11 August 2008 (UTC)

Thanks. I ran it on codepad and inserted some sample output. --Paddy3118 15:59, 11 August 2008 (UTC)

ADA program problem

The probabilities should tend to 1/3 for sticking with your original guess whereas your result seems to be 1/2 making me think you could have a problem in the Ada program. --Paddy3118 15:09, 11 August 2008 (UTC)

The number of iterations was simply not enough to get a stable random number generator on a fast machine. I have increased the number of iterations and achieved the expected results.--Waldorf 00:18, 15 August 2008 (UTC)

Probability error

Several sample outputs are suggesting that the total probability does not equal 100% which can't be right. --Lupus 11:38, 5 November 2008 (UTC)

It's just MAXScript and AWK. It may just be floating-point math errors. They aren't drastically off (less than 1% each) and the relation between switching and keeping is still apparent. --Mwn3d 14:11, 5 November 2008 (UTC)

Hi Lupus, could you give an example? There is nothing to add up to 100% that I can see - you just do say 10000 runs for each strategy and report how many times you win for each strategy and/or divide by the number of runs and multiply by 100 to get the percentage for each strategy. The strategy figures are compared but don't add up to 100%. Because its all (pseudo) random, the results should tend towards 1/3, 1/2 or 2/3 but won't exactly equal these figures. --Paddy3118 15:12, 5 November 2008 (UTC)

Oh wait, I think it is due to subtleties of the implementation Lupus. Your Fortran solution looks at what the results would be for the same random choices ran on the different strategies. Other tests just run run the same number of random trials which is what I had in mind. I haven't looked in depth at your Fortran solution though. --Paddy3118 15:19, 5 November 2008 (UTC)

Here are some examples of what I meant(I should have said percentages not probability). The Ada example appears to be doing 100000 iterations but adding up the counts give 100003. The AWK example is doing 10000 iterations but adding the counts gives 10066. The Maxscript percentages add up to 100.61%. The Perl percentages add up to 98.57%. The Python example counts add up to 99866 for 100000 iterations and the Scheme percentages add up to only 85%! The percentage chance of winning by staying plus the percentage chance of winning by switching must equal 100%. --Lupus 16:58, 5 November 2008 (UTC)

Hi Lupus, lets say you run 100000 trials and for strategy1 and get 33337 wins. You might run a second set of 100000 trials for strategy1 and get 33314 - It is random it should tend to 1/3 but It is quite allright for it not to be 1/3 +/-1. Similarly for running 100000 tests of strategy2 - It might not be exactly two thirds +/- 1. Adding up the number of wins for the two strategies I would be most surprised if it always totalled 100000 and would check things again, as these are independent random runs. --Paddy3118 17:39, 5 November 2008 (UTC)

The problem is that if you make 100000 runs, you should always switch, but remember where you started. That way, you can see if you would have won by staying and if you did win by switching all in one run. Doing it like this can guarantee that you will always record a total of 100000 outcomes. If you do 100000 runs switching and then 100000 runs staying, then you won't necessarily end up with 100000 total wins. I think Lupus is expecting that the examples only run through once checking to see if you would have won had you stayed and if you did win by switching. --Mwn3d 17:54, 5 November 2008 (UTC)