Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

A Rebol Challenge. The Monty Hall Puzzle

 [1/22] from: reichart::prolific::com at: 15-Dec-2001 23:47


We Reboler have been challenged. I was posing some puzzles with some friends on another mailing list I belong to, the enjoyment of which is provided here first should you want to try and solve this for yourself. However, one of the people responding was a programmer, and he wrote a program to try to solve the problem. First he wrote this in Pearl (183 characters), then in Matlab (136 characters). I put it to you--smarter people than I--to put this man to shame! Give me your best Rebolette, and I will make him see the error of his ways :-) OK, no looking this up on the web. This is a real fun one if you have not seen it before, or better stated, worked through it. The scenario is such: you are given the opportunity to select one closed door of three, behind one of which there is a prize. The other two doors hide "goats" (or some other such "non-prize"), or nothing at all. Once you have made your selection, Monty Hall will open one of the remaining doors, revealing that it does not contain the prize. He then asks you if you would like to switch your selection to the other unopened door, or stay with your original choice. Here is the problem: Does it matter if you switch? P.S. this problem was presented to two of my engineers and myself many many years ago. We were told that the "staff" scientist at the company of the presenter all got it wrong. So the three of us worked on it together for about 25 minutes. Came to our conclusion, then wrote a computer program to prove it. I then wrote a layman's description of "why." Which I found was needed because SO MANY PEOPLE CAN NOT ACCEPT THE ANSWER. Especially statisticians! Too funny. If anyone wants a copy, I will dig it up. Now for the Email from my friend: He writes... Nah, matlab is the way to go for this: b=sum(floor(3*rand(100,100))==0);y=floor(3*rand(100,100)); o=(floor(2*rand(100,100))+1).*(y==0)+(3-y).*(y>0);c=sum(y.*o>0); d=sum(c>b-c<b); [b;c] if (d>90) fprintf(1,"Switching is better (95%%+ confidence)\n"); end But maybe you can do better in Rebol. I don't see a way to off the top of my head. Note that if we're just comparing the core computation, the matlab is barely three lines. (The "o" variable is not strictly needed, but I am including it anyway to explicitly construct the door-picked-by-Monty.) Perl is 183 characters, not counting invocation from the command line or comments. Matlab is 136. /usr/bin/perl -e 'print "St Sw (%win)\n";$d=0;for($i=0;$i<100;$i++){ $b=0;$c=0;for($a=0;$a<100;$a++){$b+=int(rand(3))==0}; for($a=0;$a<100;$a++){$y=int(rand(3));$o=$y?(3-$y):(int(rand(2))+1); $c+=$o*$y>0;};$d+=($c>=$b)-($c<=$b);print "$b $c\n"};print "St Sw (%win)"; if ($d>90) { print "\nSwitching is better (95%+ confidence)" };print "\n"' Reichart... [Reichart--Prolific--com] Be useful.

 [2/22] from: carl:cybercraft at: 17-Dec-2001 0:15


On 16-Dec-01, Reichart wrote:
> We Reboler have been challenged. > I was posing some puzzles with some friends on another mailing list
<<quoted lines omitted: 44>>
> (%win)"; if ($d>90) { print "\nSwitching is better (95%+ > confidence)" };print "\n"'
Not being a statistician, (or having a clue what the above code does:), my approach to such problems is to simulate them many times and see if there's a noticable difference in the results. So here's my code to do that, but it may be bugged as it wasn't giving the results I was expecting. But then, what's expected is not what we're supposed to get, right? (: rebol[]k: s: 0 r: func[n][random n]a: does[p: r 3 c: r 3 p = c] loop 10000 [if a[k: k + 1]if if not a[r 2 = 1][s: s + 1]]print ["Kept" k "Switched" s] I especially like the "if if" as it sounds like an accurate description of my code. (: Anyway, it's 151 bytes long for what it's worth. -- Carl Read

 [3/22] from: sunandadh:aol at: 16-Dec-2001 6:52


Hi Reichart.
> But maybe you can do better in Rebol. I don't see a way to off the top of > my head. Note that if we're just comparing the core computation, the
matlab
> is barely three lines. (The "o" variable is not strictly needed, but I am > including it anyway to explicitly construct the > door-picked-by-Monty.)
Here's my attempt. It runs a simulated Monty 500 times. I get a "length" of 142 (length? mold load %doors.r), but I don't have the same text message as you and the "external" length could be shorter by one-lining it all and reducing the variables to W and N. The core calculation is just one line, but I'm using a different algorithm. rebol [] Win: 0 n: 0 loop 500 [ n: n + 1 win: win + last sort next random [0 0 1] ] Print ["Win%" win * 100 / n] In slow motion and with intermediate variables this is: Three doors: one has a 1 behind it (thats the car) the other two have a big zero. Doors: random [0 0 1] whichever door I pick is modelled by MyDoor: first Doors Monty then shows me a zero door: MontyDoor: mimimum Door/2 Door/3 I then select the other of Monty's doors: MySwappedDoor: Maximim Door/2 Door/3 which is the same as MySwappedDoor: last sort next Doors so if MySwappedDoor is a 1, I'm a winner! Sunanda

 [4/22] from: rotenca:telvia:it at: 16-Dec-2001 14:11


----- Original Message ----- From: <[SunandaDH--aol--com]> To: <[rebol-list--rebol--com]> Sent: Sunday, December 16, 2001 12:52 PM Subject: [REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
> Hi Reichart. > > > > But maybe you can do better in Rebol. I don't see a way to off the top
of
> > my head. Note that if we're just comparing the core computation, the > matlab > > is barely three lines. (The "o" variable is not strictly needed, but I
am
> > including it anyway to explicitly construct the > > door-picked-by-Monty.)
<<quoted lines omitted: 10>>
> ] > Print ["Win%" win * 100 / n]
Beautiful! You can remove the n + 1: Win: 0 n: 500 print ["Win%" 100 / n * loop n [win: win + last sort next random [0 0 1]]] --- Ciao Romano

 [5/22] from: brett:codeconscious at: 17-Dec-2001 0:33


Hi Reichart, The one is not as wonderous as Sunanda's solution but is interesting because you can use whatever symbols you like to represent the boxes :) The code below simulates the always switch strategy - returns rough probability of winning: REBOL[] d: {123}w: 0 loop n: 500 [ p: func[s][copy/part random s 1] b: p d c: p d if b = p union b c [w: w + 1]] w / n d: represents the choices - could have been any series of 3 elements e.g [box1 box2 box3] p: makes a random selection from a series b: the winning box c: the first choice (union b c) is equivalent to the two closed boxes after monty has opened one empty box That is it is equivalent too box-to-remove: exclude d union b c choices: exclude d box-to-remove An anxious person would probably figure out they'd more than likely goofed first go :) Cheers Brett.

 [6/22] from: rebol:optushome:au at: 16-Dec-2001 23:58


> REBOL[] > d: {123}w: 0 loop n: 500 [
<<quoted lines omitted: 4>>
> [box1 box2 box3] > p: makes a random selection from a series
Hi Brett, Just to point out a lesser known refinement of random p: func[s][copy/part random s 1] I think could be replaced by p: func[s][random/only s] Cheers, Allen K

 [7/22] from: andreas:bolka:gmx at: 16-Dec-2001 15:17


16 Dec 2001, 08:47:34, Reichart wrote:
> P.S. this problem was presented to two of my engineers and myself > many many years ago. We were told that the "staff" scientist at the
<<quoted lines omitted: 4>>
> PEOPLE CAN NOT ACCEPT THE ANSWER. Especially statisticians! Too > funny. If anyone wants a copy, I will dig it up.
I'd like to have a copy ;) -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [8/22] from: sunandadh:aol at: 16-Dec-2001 10:19


Hi Romano,
> Beautiful! You can remove the n + 1: > > Win: 0 n: 500 print ["Win%" 100 / n * loop n [win: win + last sort next > random > [0 0 1]]] >
Thanks. I thought I'd minimised it completely, but it's amazing what teamwork can do. If we just want to print the winning percentage, and we shorten the variable names we get: W: 0 n: 500 100 / n * loop n [w: w + last sort next random [0 0 1]] which is just length? {W: 0 n: 500 100 / n * loop n [w: w + last sort next random [0 0 1]]} 67 bytes. Which--spookily enough--equals our win percentage for swapping. Sunanda.

 [9/22] from: doncox:enterprise at: 16-Dec-2001 17:01


On 16-Dec-01, Andreas Bolka wrote:
> 16 Dec 2001, 08:47:34, Reichart wrote: >> P.S. this problem was presented to two of my engineers and myself
<<quoted lines omitted: 6>>
>> funny. If anyone wants a copy, I will dig it up. > I'd like to have a copy ;)
If it's not too long, post it. Regards -- Don Cox [doncox--enterprise--net]

 [10/22] from: rotenca:telvia:it at: 16-Dec-2001 17:33


Hi Sunanda,
> Thanks. I thought I'd minimised it completely, but it's amazing what
teamwork
> can do.
Nothing in front of your wonderful: last sort next random P.S. Are you from India? --- Ciao Romano

 [11/22] from: rebol665:ifrance at: 16-Dec-2001 17:37


Hi Romano and Sunanda, Your work is brilliant ! It helps me to get to the problem, and finally my 17 years'old son explained it to me. If you consider that each time I loose I did not win, the answer can be shorten a bit. rebol[] win: 100 print ["Win% = " loop win [ win: win - first random [0 0 1]]] It is a beat cheatting considering that your version iterate 500 times so I give also my 1000 iterations version. rebol[] win: 1000 print ["Win% = " (loop win [ win: win - first random [0 0 1]]) / 10] These are respectively 43 and 51 bytes long. Patrick

 [12/22] from: g:santilli:tiscalinet:it at: 16-Dec-2001 15:27


Hello Reichart! On 16-Dic-01, you wrote: R> Does it matter if you switch? Readable version: random/seed now no-switch-wins: 0 switch-wins: 0 loop 1000 [ winning: random 3 your-choice: random 3 either your-choice = winning [ no-switch-wins: no-switch-wins + 1 ] [ switch-wins: switch-wins + 1 ] ] print [ "If you switch, you win" switch-wins "times" newline "If you don't switch, you win" no-switch-wins "times" ] Compact version: r: does[random 3]n: s: 0 loop 1000[either r = r[n: n + 1][s: s + 1]] print [ "If you switch, you win" s "times" newline "If you don't switch, you win" n "times" ] I presume the code you show is doing something different, but I don't speak perl or matlab... :) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [13/22] from: sunandadh:aol at: 16-Dec-2001 14:18


Hi Patrick,
> Your work is brilliant ! It helps me to get to the problem, and finally my > 17 years'old son explained it to me. If you consider that each time I loose > I did not win, the answer can be shorten a bit.
Thanks,
> rebol[] > win: 100 print ["Win% = " loop win [ win: win - first random [0 0 1]]]
<<quoted lines omitted: 4>>
> 10] > These are respectively 43 and 51 bytes long.
Good stuff! Your solutions embody the logic that : 1. If I stick with what I've got, I've a 1/3rd chance of winning 2. Therefore Monty has a 2/3 chance of having the car 3. But Monty has shown me an empty door, So, if Monty has the car it MUST be behind the door he didn't open. 4. Therefore I'll take that unopened door and win 2/3s of the time Given we all accept that logic, that, we could shorten the puzzle even more: Print ["Win% " 200 / 3] <g!> The problem being that not everyone does accept that logic at first view. So, to be fair, we need code that runs a fair emulation of making a choice. Sunanda

 [14/22] from: sunandadh:aol at: 16-Dec-2001 16:43


Hi Romano, P.S.
> Are you from India?
Sorry No. Irish descent, living in Birmingham, England. Sunanda.

 [15/22] from: rebol665:ifrance at: 16-Dec-2001 22:54


Hi, Sunanda Print ["Win% " 200 / 3] I came to the same conclusion thanks to your "slow motion" explanation but I did not dare to put that. Indeed the 2/3 emerges from your explanation.
>so if MySwappedDoor is a 1, I'm a winner!
Actually this already points to "how can that happens if the 1 comes first in the block?". However it was not my aim to "stole your thunder" (as would Monica Geller say*).
>The problem being that not everyone does accept that logic at first view.
My version could have come without any assumption, even without knowing what it was all about. Your program was counting how many times a random block including two zero and only one one could either be [0 0 1] or [0 1 0]. My version said that it suffice to count how many times it would not be [1 0 0]. I must confess that I too prefer your version that not only gives the answers but also "explains" it. That was a very very clever piece of code ! Patrick ps: * comes from the serie FRIENDS, episode 701

 [16/22] from: brett:codeconscious at: 17-Dec-2001 11:34


Hi Allen, You're right. I didn't know about that refinement. I would have used "first random s" instead of "random/only". But here though, I used copy/part because I needed a series to work in the union operation. Otherwise I'll need to add "to-string" before the "random/only" and d will need to be restricted to being a string only. Doing this yields, REBOL[] d: {123}w: 0 loop n: 500 [ p: func[s][to-string random/only s] b: p d c: p d if b = p union b c [w: w + 1]] w / n Which is about 3 characters longer than the original :) Cheers Brett.

 [17/22] from: joel:neely:fedex at: 16-Dec-2001 16:20


Hi, Sunanda, et al, It seems to me that the problem in the original post was persuasion and not just computation. That being the case, the text of the program itself (or its derivation) should be a compelling argument for the right answer. IOW, if I had trouble understanding/accepting an answer, I would not be very persuaded simply by the output of a highly compact program that seemed to contain assumptions about the very answer I was having trouble with. That said, let me offer two lines of reasoning (starting with the same assumptions -- one argument based on verbal reasoning and one based on code refactoring) which might be of some persuasive value (but YMMV). **************** * ASSUMPTIONS: * **************** 0) There are three doors. 1) The prize door is chosen at random. 2) The contestant chooses a door at random. 3) Monty chooses and opens a door at random that is neither the prize door nor the contestant's door. ******************** * VERBAL ARGUMENT: * ******************** Imagine that there are two contestants playing as a team. They agree on an initial guess (randomly chosen, remember), but then one (A) always keeps the initial guess, while the other (B) always switches after Monty opens a door. Since Monty always opens a non-prize door (leaving two doors unopened) exactly one of them must win on every round. Since Monty opens the non-prize door after the initial guess is chosen, his choice of which door to open changes neither the initial guess nor the door behind which the prize has already been placed. Therefore, A's chances of winning are unaffected by what Monty does. Since A is choosing randomly to find the winning one door out of three, his odds of winning are 1/3, and his odds of losing are 2/3. Therefore, B's odds of winning are 2/3 (B wins whenever A loses). ************************* * REFACTORING ARGUMENT: * ************************* Implementing the assumptions (using RANDOM) and trying a bunch of rounds, we get something like this (in my best commented-to-death style -- remember that we're explaining to a skeptic ;-) : 8<------------------------------------------------------------ pickadoor: function [ rounds [integer!] ][ prizedoor guessdoor montydoor keepwins switchwins ][ ; ; neither strategy has won anything before we start ; keepwins: switchwins: 0 ; ; simulate the specified number of rounds ; loop rounds [ ; ; prize is behind a randomly-chosen door ; prizedoor: random 3 ; ; contestant (or team) randomly guesses a door ; guessdoor: random 3 ; ; Monty opens a non-prize, non-guessed door ; until [ montydoor: random 3 all [montydoor <> prizedoor montydoor <> guessdoor] ] ; ; which strategy won on this round? ; either guessdoor = prizedoor [ keepwins: keepwins + 1 ][ switchwins: switchwins + 1 ] ] print [ "Keep won" keepwins "rounds," "switch won" switchwins "rounds" ] ] 8<------------------------------------------------------------ Having started with a painfully explicit (but obviously valid -- I hope!) function, let't start compacting and refactoring. I'll save my typing time and your bandwidth and reading time by omitting the comments from here on... Step 1: Since KEEPWINS + SWITCHWINS is always equal to rounds played thus far, we don't need both variables. Let's eliminate SWITCHWINS throughout the code. 8<------------------------------------------------------------ pickadoor: function [ rounds [integer!] ][ prizedoor guessdoor montydoor keepwins ][ keepwins: 0 loop rounds [ prizedoor: random 3 guessdoor: random 3 until [ montydoor: random 3 all [montydoor <> prizedoor montydoor <> guessdoor] ] if guessdoor = prizedoor [ keepwins: keepwins + 1 ] ] print [ "Keep won" keepwins "rounds," "switch won" rounds - keepwins "rounds" ] ] 8<------------------------------------------------------------ Step 2: Since KEEPWINS only depends on the values of GUESSDOOR and PRIZEDOOR (but *not* on MONTYDOOR), we can eliminate MONTYDOOR from the code. 8<------------------------------------------------------------ pickadoor: function [ rounds [integer!] ][ prizedoor guessdoor keepwins ][ keepwins: 0 loop rounds [ prizedoor: random 3 guessdoor: random 3 if guessdoor = prizedoor [ keepwins: keepwins + 1 ] ] print [ "Keep won" keepwins "rounds," "switch won" rounds - keepwins "rounds" ] ] 8<------------------------------------------------------------ Step 3: The variables PRIZEDOOR and GUESSDOOR are set to a new value once per loop, and then examined exactly once per loop; therefore, we can eliminate the variables by using their defining expressions instead of their (single) usage. 8<------------------------------------------------------------ pickadoor: function [ rounds [integer!] ][ keepwins ][ keepwins: 0 loop rounds [ if (random 3) = random 3 [ keepwins: keepwins + 1 ] ] print [ "Keep won" keepwins "rounds," "switch won" rounds - keepwins "rounds" ] ] 8<------------------------------------------------------------ At this point, a symmetry argument should suffice to persuade that the output converges to 1/3 and 2/3 (assuming that the PRNG is valid). Step 4: Apply symmetry; the choice of 3 is irrelevant. 8<------------------------------------------------------------ pickadoor: function [ rounds [integer!] ][ keepwins ][ keepwins: 0 loop rounds [ if 3 = random 3 [ keepwins: keepwins + 1 ] ] print [ "Keep won" keepwins "rounds," "switch won" rounds - keepwins "rounds" ] ] 8<------------------------------------------------------------ Step 5: Just for fun, let's get dense! Compacting words to one-letter names, pruning constant output strings, and eschewing layout whitespace... 8<------------------------------------------------------------ REBOL []p: function [n][k r][k: 0 loop n[if 3 = r 3[k: k + 1]]print[k n - k]] 8<------------------------------------------------------------ Step 6: If we're willing to pollute the global namespace, forego the function, and type the one-liner into the interactive console each time... 8<------------------------------------------------------------ n: 10000 k: 0 loop n[if 3 = random 3[k: k + 1]]print[k n - k] 8<------------------------------------------------------------ But, IMHO, the persuasion is in the process by which we arrived at the last version (or maybe a version or two before that... ;-) and not in its raw output. -jn- PS: As I've mentioned before, I have a random process that picks the sigs on this box. The resonance between topic and the randomly chosen sig per message has been *really* freaky today! -- If you think big enough, you'll never have to do it. -- Reisner's Rule of Conceptual Intertia joel:FIX:PUNCTUATION:dot:neely:at:fedex:dot:com

 [18/22] from: carl:cybercraft at: 17-Dec-2001 21:13


On 17-Dec-01, Carl Read wrote:
> Not being a statistician, (or having a clue what the above code > does:), my approach to such problems is to simulate them many times
<<quoted lines omitted: 8>>
> description of my code. (: Anyway, it's 151 bytes long for what it's > worth.
I thought the above was bugged, and it was. Here's a fixed version... rebol[]k: s: 0 r: func[n][random n]m: does[p: r 3 c: r 3 p = c] loop 10000 [if m[k: k + 1]if not m[s: s + 1]]print ["Kept" k "Switched" s] Nowhere near as short as some of the other posts, but anyway, here's my reasoning behind it... The prize is placed behind one of 3 doors... prize: random 3 You choose one of the doors... chosen: random 3 Now, Monty can see if they're a match - ie, if you've picked a winner... matched?: prize = chosen Which returns true if you've chosen the prize. If you decide to keep this then it's obvious (I hope:) that you had 1 chance in 3 of picking the prize. But what if you accept Monty's offer to switch? Well, there's only two posibilities: 1) You'd chosen the prize, so switching from that means you lose regardless of what Monty does. 2) You hadn't chosen the prize, Monty exposes the other losing door, and so you switch to the winning door. So a switch always means a reversal of your original choice - a winning choice becoming a losing one and vice-versa. So... matched?: not matched? But what happens to the "1 chance in 3 of picking the prize."? Well that also means you had 2 chances in 3 of losing, right? And the switch makes an original loss a win, so switching gives you 2 chances in 3 of winning, thus doubling your chances of a win. Note that I originally (though vaguely) thought switching would improve your chances from 1 in 3 to 1 in 2, but this result is much more fun. (: -- Carl Read

 [19/22] from: sunandadh:aol at: 17-Dec-2001 9:39


Hi Joel,
> It seems to me that the problem in the original post was persuasion > and not just computation. That being the case, the text of the
<<quoted lines omitted: 4>>
> program that seemed to contain assumptions about the very answer > I was having trouble with.
I completely agree that a highly compressed program isn't often a great way to win an argument. But (just to defend myself for a moment) my attempt embodied all the "rules": I picked a door; Monty picked an empty one of the other two; I swap to his unopened one. No built-in assumptions there. i also agree with an earlier post of yours (about Perl and parlor games). The best test of a programming language isn't how compact a program it can write, but (I would claim) how easy it is to write maintainable programs in it. But even that tests mainly the design skills and long-term vision of the programmer. A good test of all of our (and Perl and Matlab) solutions is how easily can they be modified as various "real world" changes are required. Almost by definition, we can't know what our programs will face over there lifetimes, but here are a few of the sort of things that might beset a Monty simulator: -- Not three doors, but 10 -- Not 10 but 25 million doors (challenging many language implementations to handle this as in-store arrays) -- Monty opens more than one door --there is more than one door with a car behind it -- I get to pick more than one originally, but can only open ONE of mine, OR one of his once Monty has opened the ones on his side -- I get to pick more than one door, and Monty opens N of mine and M of his. -- There are several prizes (a Saab and a Mercedes) including some booby prizes (A tribe and a yugo maybe). Monty will open up to N doors at random; I can't win the prize behind an opened door; but I can tell him to stop at any moment, and then make my choice. -- The program running as a CGI is so overwhelming popular that it is swamping the server: rewrite it to use half the cpu cycles. -- The government will buy 3,000,000 copies but only after the simulation is run not 500 times but 500,000,000 times. (Rebol can handle this number, but for most languages Wins + 1 = Wins for a sufficiently large value of Wins. If you exceed that, you need extra special code). I can see how my solution will naturally extend for some of these; can be bodged into shape for others; and would be scrapped and rewritten for the rest. And that's programming! Sunanda.

 [20/22] from: joel:neely:fedex at: 17-Dec-2001 12:27


Hi, Sunanda, [SunandaDH--aol--com] wrote:
> I completely agree that a highly compressed program isn't often a > great way to win an argument. But (just to defend myself for a > moment) ... >
No defense necessary (except perhaps on my part for poor choice of wording -- perhaps I should have said "inferences" or "conclusions" instead of "assumptions")! All I meant was that several of the very compact solutions were the *result* of reasoning about the problem, rather than a *record* of the reasoning process itself. In such a situation, a skeptical audience simply shifts its skepticism to the program itself, rather than having its skepticism relieved.
> The best test of a programming language isn't how compact a program > it can write, but (I would claim) how easy it is to write maintain- > able programs in it. But even that tests mainly the design skills > and long-term vision of the programmer. >
Per your following discussion, I believe we'd agree that "ability to guess -- most of the time -- what is likely to change in the future" is an important part of "long-term vision".
> A good test of all of our (and Perl and Matlab) solutions is how > easily can they be modified as various "real world" changes are > required. Almost by definition, we can't know what our programs > will face over there lifetimes, but here are a few of the sort of > things that might beset a Monty simulator: >
...
> I can see how my solution will naturally extend for some of these; > can be bodged into shape for others; and would be scrapped and > rewritten for the rest. And that's programming! >
A *VERY* interesting and thought-provoking list! Thanks! -jn-

 [21/22] from: carl:cybercraft at: 18-Dec-2001 11:57


On 17-Dec-01, Carl Read wrote:
> Here's a fixed version... > rebol[]k: s: 0 r: func[n][random n]m: does[p: r 3 c: r 3 p = c] loop
<<quoted lines omitted: 25>>
> switch makes an original loss a win, so switching gives you 2 > chances in 3 of winning, thus doubling your chances of a win.
After showing the above explaination to someone (not on this list) they still didn't believe it, so I've written a graphical version in the hope that pictures will win out where words fail... (Not a View version though - run it from the Console.) rebol [] doors: func [n c][ d: copy/deep ["[ ]" "[ ]" "[ ]"] d/:n/2: c return d ] game: does [ print " Switching Keeping" prize: random 3 print ["Prize: " doors prize #"P" " " doors prize #"P"] guess: random 3 print ["Guess: " doors guess #"G" " " doors guess #"G"] opened: first random difference [1 2 3] reduce [prize guess] prin ["Opened:" doors opened #"X"] prin " " print either prize = guess [kept: kept + 1 "Win"]["Loss"] sw: first difference [1 2 3] reduce [guess opened] print ["Switch:" doors sw #"S"] prin " " print either prize = sw [switched: switched + 1 "Win"]["Loss"] played: played + 1 print [ "Wins: " switched " " kept " Played:" played ] ] played: 0 kept: 0 switched: 0 quit?: false print "" while [not quit?][ game print "" print "Enter to continue - Esc to quit." inp: input quit?: inp = "q" ] Enough! (: -- Carl Read

 [22/22] from: nitsch-lists:netcologne at: 18-Dec-2001 0:41


RE: [REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle [carl--cybercraft--co--nz] wrote:
> On 17-Dec-01, Carl Read wrote: > > Here's a fixed version...
<<quoted lines omitted: 30>>
> the hope that pictures will win out where words fail... (Not a View > version though - run it from the Console.)
well, thats to complicated to me, i give up. i have a 2/3 choice to get a priceless door, this chances are better, and so i want to be priceless. hey, and if i hit, Monty will show me the other priceless door! so i have two :) happy without a price -Volker ;-)

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted