4
retoor
65d

I solved the Monty Hall problem for once and for all! Suckers. Of course a computer can't decide if switching or keeping is the best choice. Even wikipedia states that switching wins. NEVER. And even if that would be the case, it's pure how you arranged the labels to determine which one wins. If everyone actually wrote their own code, the conclusion wouldn't be what it is now. Many people probably just changed their code until that false result comes out or had it at the beginning caused by lack of experience.

Here is a GOOD implementation: https://pastebin.com/dRiTWQpw

It gives a 50%-ish chance on a choice like mathematically is correct.

The problem is in the computer simulations: using > or < to check which choice has won. But actually, often no one has won (it's a tie) after running it x times so you have to filter out the ==.

Then, you get the right results. My first version also had a bias, but i refused to accept it and did spent 45 minutes on the code instead of 15. This is the end result. And no, with double ?: in a printf statement i don't expect a prize.

It was a lot of fun actually, did not expect this from such stupid 'problem'

Comments
  • 0
    It's good not doubting thyself. Because the first version of my code was biased too. I could've quit like "Oh, hmm. Indeed. Strange, but internet says so, so it must be true" against my own beliefs. I won't even bother to make an update to the wikipedia page. I can already imagine how much discussion it'll cost. Probably code of original simulation is lost or so. And even if they didn't make the > or < mistake - it still could've been their random back in the day. But how can you say a certain choice wins since the sequence of the choices can just be switched if you want. Switch wins because you wanted to...
  • 1
  • 1
    I remember doing a simulation too some time ago and I got the canonical 67%/33% result.
    I'll take a look at your code later, I'm curious.
  • 0
    @cafecortado yes - a 20%-ish margin to one door. It's caused by using > and < but you should check == before, that's a result that doesn't count. If you use only < and >, you have a bias
  • 0
    @cafecortado I do realize that I first let the showman choose a door and after i decide what door the prize is. That doesn't matter. I did build it in later because I forgot about the prize in the beginning. I just started typing not expecting that it did require some effort. Didn't take it serious
  • 3
    It depends on if Monty knows what the real door is. If he doesn’t, there’s no value in switching. If he does, he’s always going to show you a door that’s false. I, too, wrote a simulator once upon a time. https://github.com/AmyShackles/...
  • 1
    @AmyShackles I'm now checking someone's python code regarding Monty Hall. It uses several include and exclude actions on several list. Quite hard code.

    But one thing is for sure, the answer isn't 1/3. He guarantees to open a door without car. So the odds are always a half. 50/50. and from that 50/50 you have 50/50 again. It stays 50/50. It doesn't become 50/50 of 50/50 what still wouldn't make up from a third. That first door is pure destraction. No part of calculation
  • 2
    @retoor thanks for calling me here, but I have to ask, now that I'm here, how does this apply to prime factorization? (lol)
  • 1
    @Wisecrack I just call you for nerdy shit and maybe code review? 😁
  • 1
    I am playing with it and it seems that if I put the order right (i.e. first choose the prize, then the first choice and then the showman choice) I get that switch always wins. Because that way those whiles and ifs have a different logic (the correct one?).
  • 1
    I think the way you are doing it is fucking up the probabilities somehow because half of the time (instead of a third) the first choice door equals the prize door.
  • 1
    @cafecortado hmm, that's correct but prize is never behind the door the showman chooses right? The third door is not a option to choose?
  • 1
    @cafecortado thanks a lot of checking, dissapointed how many don't do :)
  • 1
    @retoor yep, but I guess that by making door_first_choice dependant on door_showman_choice, instead the opposite, you are getting the distribution of probabilities wrong or something
  • 1
    @cafecortado I can't choose the door of the showman right? Lemme check
  • 1
    @cafecortado according to code it can be any door that's not showmans door. I think that's right
  • 1
    @cafecortado according to GPT:

    ```

    Why Switching Works:

    If you initially picked the car, switching makes you lose (this happens 1/3 of the time).

    If you initially picked a goat, Monty's action of revealing the other goat means that switching will give you the car (this happens 2/3 of the time).

    ```

    But you have no idea that the door you initially picked has the goat right? So, the chance stays 50/50?

    In my code, Monty picks the door first, not you. But i don't think that matters since Monty will always open a door and you'll always have option to switch. I think the third door is a complete unrelated distraction. You never had 1/3rd choice
  • 2
    @retoor I don't know, too much thinking for a Sunday 🙃
  • 2
    @retoor I’m terrible at math, but the way I remember it…

    You pick a door. There’s a 1/3 chance the door you picked has a car.

    Monty picks a door. Monty knows where the car is and he will never choose a door that has the car because he knows where the car is. So there’s a 0/3 chance that the door he picks is the car.

    That leaves a 2/3 chance that the door no one picked is the prize door, because the probability that you picked the prize door doesn’t change when Monty picks a door.
  • 1
    @AmyShackles Yes, that's exactly my reasoning. It's 0/3. Monty and his door doesn't change a thing. It' pure distraction. Would be different if he could pick the car door. So in the end: you're always dealing with 50%. It's your door or the other one. What Monty does, doesn't matter. The car doesn't move or smth. Since it's guaranteed that Monty opens a door, how can it ever be 1/3rd to pick a door or something with a 3rd at all.

    "one of the most prolific mathematicians in history, remained unconvinced until he was shown a computer simulation demonstrating Savant's predicted result.". Ironic, a mathematician trusts the simulation more while I as dev trust the math more.

    I'll got to the bottom of this. I even checked what happens if you execute random a time more and stuff. If random gets executed an uneven (or maybe opposite) times, it could become become biased if you some it up in theory.

    A friend of mine said that after rewrite "keeping" was the 2/3'rd result. Heh
  • 2
    Put another way:

    If neither Monty or you knew where the car was, there’s a 1/3 chance for all the doors.

    The probability of the door no one picked and your door being the prize door isn’t 50/50 because your choosing the correct door is independent of Monty choosing the remaining door without a prize.

    Scenario 1:
    Prize door is A
    You pick A
    Monty picks B
    Switching loses

    Scenario 2:
    Prize door is A
    You pick A
    Monty picks C
    Switching loses

    Scenario 3:
    Prize door is A
    You pick B
    Monty picks C
    Switching wins

    Scenario 4:
    Prize door is A
    You pick C
    Monty picks B
    Switching wins

    Fuck now it feels like 50/50 again. I hate this problem so much lol
  • 0
    @AmyShackles you made me very worry for a while with your correct reasoning until I noticed that your outcome was 50/50 😂 Imagine having written a post like I did with such phrasing here above being wrong and that chance is still quite possible 😂 More possible than having */3rd change imo 😂 Let's say around 50% 😁
  • 1
    @retoor Sorry for the scare, friend 😅❤️
  • 0
    @AmyShackles it's OK. I already reserved a place as the female C dev on the Github Ark of Noah anyway a while ago (see my comment): https://devrant.com/rants/11244312/...

    But i'm tired. I had to read your reasoning very slowly. I do not underestimate this problem anymore :P
  • 1
    @AmyShackles the trap with those 4 scenarios is that they don't occur the same number of times. Instead, the 1st and 2nd *combined* ocurr 1/3 of the time (because you only pick A 1/3 of the time) , the 3rd ocurrs other 1/3 of the time and the 4th the other 1/3 of the time. So considering this, at the end you will get 2/3 of switching.
  • 1
    @cafecortado wow. That's deep. Can't render than now :P But i get the idea
  • 2
    @cafecortado I *thought* it was something like that, but I’m pre-caffeine and ADHD meds and my brain was like “nopenopenope”
  • 1
    @AmyShackles

    The problem changes significantly if 1. you consider 'runner-up' or spoiler prizes for losing (which shows sometimes hand out for audience sympathy points) (inclusive) and 2. if monty doesn't know which door either.

    Whys that?

    You pick door #1, monty picks door #2.

    What are the odds that you jointly or both picked the wrong door?

    The only way to reduce the chance of gaining *any* prize, is by switching to monty's door, or picking door #3.

    This assumes none of the doors are opened till 1. after you pick your initial door, and 2. after you decide whether to switch or not.

    If instead you open your initial door first, and theres nothing, then it becomes a game of

    if monty chooses at random, or if monty always picks the door that doesn't have a prize.

    If monty picks the door at random, and you open your initial door to find no prize, then the odds come down to the same question: what were the odds you were *both* wrong when monty and you chose doors?
  • 1
    as an aside it also assumes monty chooses his own door before any doors are actually opened, and he chooses his door after your own initial choice.
  • 2
    @Wisecrack yes, my code does that but i thought it didn't made a difference in the end.

    Reason why I did it that way is because i didn't knew better, I've learned about the monty hall problem in a bar years ago. Also have learned lisp in a bar. Python on the streets. Last one is a joke. Lisp happened. Silly language
  • 2
    @retoor i know lisp too. Just look at the amount of parenthesis I use in my math
  • 1
    @Wisecrack finally finished my regex parser. Started on it yesterday morning. Wrote it in one day. Previous versions took weeks. Can you imagine how much you learn. Mind you: i do everything from scratch without doing research upfront - i check such stuff afterwards to see if i did good. So far, it beats in performance the C regex parser. It's full featured 623 lines without tests. Tests are separate file. I had to find a balance between good code and performance. I use the regex code itself as bytecode, no bytecode compiler needed :D
  • 1
    Wait it's really that fast?

    Also what do you mean you use the code as bytecode?
  • 1
    @Wisecrack a byte is same size as a char. Since every function in regex is one char (!? +*{[), I've put 254 function references in an array. array['('] is mapped to brace_open function for example. Most items in array are mapped to a function for literal comparison. My code doesn't contain code to figure out what function to execute. It knows directly. To give idea in python it would be:
    functions = [fn1, fn2]:
    for c in "^p*pony$":
    functions[c](strtovalidate)

    Strtovalidate gets moved / shorter after every validation function called

    Edit: a precompiler still could be useful to clean up some code but result would be very minimal and only usefull if you're gonna validate a million strings or so. There's not much to optimize anymore
  • 1
    @retoor that is way fucking cool.

    Sort of like what I'm doing with my graph model, where graph tokens are function that manipulate the context embedding.
Add Comment