4 ms·
Your code doesn't really provide "proof." You've completely omitted the host's door elimination. I know in the end it doesn't matter, but if you already knew th
by aston 18y ago
Your code doesn't really provide "proof." You've completely omitted the host's door elimination. I know in the end it doesn't matter, but if you already knew the answer you would code the simulation in the first place, right?
- tc 18y agoNot that this really needs another implementation, but since I already wrote it before seeing this thread... (defun monty-hall (strategy &aux (winner (random 3)) (choice (random 3))) (let ((monty (if (= winner choice) (do ((x (random 3) (random 3))) ((/= x winner) x)) (- 3 (+ winner choice))))) (case strategy (:stay (= winner choice)) (:change (= winner (- 3 (+ choice monty))))))) (looping and reporting omitted) Incidentally, I think the code in the original article provides a good example of how code can be so verbose as to detract from understanding. Good code clarifies a problem rather than obfuscating it under the weight of useless detail.
- axiom 18y agoYou make a good point, and there is definitely some value to including that step (although it would be only another 2 lines of code actually.) I considered putting it in, but didn't because of the following: 1. The only leap of logic required is to realize that the two options are mutually exclusive: either you win by staying or you win by switching. There is no alternative. 2. Writing the code in that concise form, I believe the inherent structure of the problem is much clearer than the mess of classes and function calls.