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)