DEV Community: Oluwole Ajewole

Scripting The Monty Hall Problem

Oluwole Ajewole — Mon, 08 Nov 2021 06:08:26 +0000

Ahoy!

If like me your eyes glisten and your ears perk up when you come across deceptive math puzzles, you are sure to find some value in this piece. Here, I introduce the Monty Hall problem, discuss a useful way to think about the solution, and present a python script I wrote to validate it.

The Monty Hall Problem

The Monty Hall problem (named after Monty Hall, a game show host) is a rather deceptive brain teaser that became somewhat popular towards the end of the 20th Century. It is not a difficult problem to understand as it contains very simple premises but it is, nevertheless, pretty tricky to solve.

Like the Ball And Bat Problem, psychologists often use the Monty Hall problem to illustrate how easily humans can fail to grasp the "math" or the "rational", opting instead for the "immediately obvious" or "intuitive" response. They call out our tendency to introduce bias and other forms of heuristics when making decisions—preferring easier, less laborious, and inaccurate approaches to more tasking, and more accurate ones.

What I find most amusing and fascinating about such problems that is that we are usually very aware that they are tricky problems—tricky problems that we are probably hearing about because they've most likely conquered the minds of many people. Yet, we dive in to answer them, optimistic that we'd give a correct response. But of course, we are usually wrong—like I and most people were with the Monty Hall Problem. And even when we are presented with the correct answer, it could be pretty difficult to wrap our heads around the right answer.

The Monty Hall problem tests our understanding of probabilities in some sort of illusory manner. Here is my variant of the problem:

Say you are Luffy, a pirate searching for the grandest treasure—The One Piece. Say there are three identical maps, one of which leads you to the treasure. The other two maps lead you to a wasteland filled with sand. Of course you want the treasure, but you don't know which of the three maps has the treasure. You can't differentiate one from the other.

Say the maps have a custodian, Monty Hall, and he knows what map leads where. In other words, Monty Hall knows which maps lead you to a wasteland and the one that can guide you to the treasure. He decides to play a game with you as follows;

You are to pick any one of the three maps (at this point, you don't know if your chosen map leads you to the treasure or to a wasteland)
Next, of the other two maps, Monty Hall picks one map that leads to a wasteland. Remember, he knows where each map leads to and he always picks a wasteland map.
At this point you have picked one map (that may or may not lead to the treasure) and Monty Hall has picked a map that definitely leads to the wasteland. Monty's map needn't be considered anymore, but there is a third map that neither of you chose.
Next, Monty Hall asks you; do you want to stick with your initial selection or do you want to switch your selection to the third map?

That's the problem statement. You are given a choice to stick with your initial map selection or switch to the third map that neither of you chose. Will you stick or switch?

The Answer

With little or no deliberation, we are tempted to choose to stick with our original decision. This is because we believe that switching to the third map would not change the odds that we chose the right map. Our mind is heavily focused on the probability that our first choice was correct, and switching seems like an unnecessary risk. We could also think, perhaps, that after that after Monty Hall chooses the second map, the probability that our original selection is the treasure map is equal to the probability that the third map is the treasure map, i.e. 1/2 each since there are now two options. So there is no point switching. But that is not so!

It may take some time to sink in, but here is what I consider a useful approach to analysing the problem;

At the start, when you make the first selection

the probability of picking a treasure map is 1/3;
and the probability of picking a wasteland map is 2/3

In other words, you are more likely to pick a wasteland map than a treasure map.

Next, regardless of your choice, Monty Hall will always pick a wasteland map.

After Monty picks, there are two possible scenarios; either the third unselected map is the treasure map or it is another wasteland map. And these two scenarios play out probabilistically in relation to your first choice in the following ways;

if the third unselected map is a wasteland map, it must mean that your first selection was the treasure map. This happens one-third of the time (1/3) as stated above. And therefore, you'd win if you don't switch
if the third unselected map is the treasure map, it must mean that your first selection was a wasteland map. This happens two-thirds of the time (2/3) as stated above. And therefore, you'd win if you switch

As such, since your first selection is likely to be a wasteland map than the treasure map, it makes statistical sense to always switch to the third map. Of course, winning is not guaranteed by switching. But you are twice as likely to win when you switch than when you stick to your first selection. So always switch!

The Python Script: Some Evidence

It is normal to still have doubts about the solution to the Monty Hall problem. A useful way to perhaps, cement your belief in and acceptance of the answer is to simulate the problem several times. This is exactly what I did with using a Python Script. You can find the gist here and the repo here.

Let's walk through the code;

First we import the random module. We define a function called single run that initializes our map trio as an array. We select a random map to contain our One Piece treasure and the function returns the map array.

# The Monty Hall Problem

import random

# Instantiating a random treasure map
def single_run():
    maps = ['wasteland', 'wasteland', 'wasteland']
    treasure_index = random.randint(0, 2)
    maps[treasure_index] = 'one piece'
    return maps

Next, we define a function that returns Luffy's random first choice

# Luffy's first choice
def luffy():
    luffy_first_choice = random.randint(0, 2)
    return luffy_first_choice

Next, we define a function that returns Monty's choice of a wasteland map. We use a while loop to ensure that Monty's chosen map is neither Luffy's first choice nor the treasure map.

# Monty's choice of a location that is neither Luffy's choice nor the treasure location
def monty(maps, luffy_first_choice):
    monty_choice = 0

    while monty_choice == luffy_first_choice or maps[monty_choice] == 'one piece':
        monty_choice += 1

    return monty_choice

Next we define a function that returns Luffy's switched choice. Note that this function is not necessary for the simulation. I only included it for the sake of completeness.

# switch Luffy's choice
def luffy_switch(luffy_first_choice, monty_choice):

    luffy_switch_choice = 0

    while luffy_switch_choice == luffy_first_choice or luffy_switch_choice == monty_choice:
        luffy_switch_choice += 1

    return luffy_switch_choice

Next, we define a function that returns the output. It accepts as input, the number of times switching yielded the treasure map, the number of times sticking yielded the treasure map, and the number of trials. It returns the percentages for both decisions as part of a string.

# output to be displayed
def output(stick, switch, trials):
    stick_percent = round((stick/trials) * 100)
    switch_percent = round((switch/trials) * 100)

    print(f'Luffy found One Piece {stick_percent} % of the time when he decided to stick to his initial choice ')
    print(f'Luffy found One Piece {switch_percent} % of the time when he decided to switch his initial choice')

And we have the body of the script. It accepts the number of trials as input, i.e. the number of simulations you want to run. We also initialize the number of times sticking and switching yield the treasure map to zero.

We run our loop as many times as the number of trials. Inside the loop, we use are already defined functions to;

get the maps array
randomly make Luffy's initial map choice
make Monty choose a wasteland map
switch Luffy's initial choice
increment the stick_count if the initial choice has the One Piece treasure
increment the switch_count if the switched choice has the One Piece treasure

print('The Monty Hall Problem')
trials = int(input('Enter the number of trials:  '))

# Luffy sticks
stick_count = 0

# Luffy switches
switch_count = 0

for i in range(trials):
    maps = single_run()
    luffy_first_choice = luffy()
    monty_choice = monty(maps, luffy_first_choice)
    luffy_switch_choice = luffy_switch(luffy_first_choice, monty_choice)

    if maps[luffy_first_choice] == 'one piece':
        stick_count += 1

    elif maps[luffy_switch_choice] == 'one piece':
        switch_count += 1

output(stick_count, switch_count, trials)

Note, as mentioned earlier, that we don't need the luffy_switch function, and by implication we can do without incrementing the switch_count as we have done. That's because we are sure that if Luffy's initial choice was the treasure map, then the third choice is definitely not the treasure map. In the same vein, if Luffy's initial choice wasn't the treasure map, then the third choice that could have been switched to would be the treasure map.

In other words, the treasure map is either the original choice or the switched choice. The incidences of both (stick_count and switch_count ) necessarily add up to the number of trials. So we can use simple arithmetic to evaluate one if we have the other; switch_count = trials - stick_count. That's definitely a more concise way of writing this script. I only wrote it this way for the sake of completeness.

Conclusion

The result of running the Python Script (several times) proves that Luffy gets the treasure map about two-thirds (2/3) of the time when he switches as opposed to one-third (1/3) of the time when he sticks with his original choice.

And that's The Monty Hall Problem. The key thing to remember is to always switch maps after Monty Hall chooses a wasteland map because your initial choice was more likely wrong than correct. As such, switching improves the chances that you'd win the treasure map.

And when you find the treasure, remember to share it with me! A comment, a like, a repost, some feedback—anything will do!

Thanks for reading!
Also connect with me:

LinkedIn: Wolemercy
Twitter: Wolemercy
GitHub: Wolemercy

Building A URL Shortener Application

Oluwole Ajewole — Tue, 10 Aug 2021 11:15:49 +0000

Welcome to my first of many #DEV posts!

Introduction
Development
Deployment
Lessons

Introduction

As part of my dev growth, I thought I'd build an application that ticked the following boxes:

functionality: it should serve a specific purpose rather than just be a dummy
usefulness: users should derive some meaningful merit from it
instructiveness: it should be to me, an opportunity to learn and improve my software engineering skills

Of course, there are other needs—in addition to the ones aforementioned—that applications should fulfil, but I reasoned it best to focus on those three for now. It resulted in me building a URL Shortener App that is scalable and ultimately, satisfying.

This post is not a "How To" guide on recreating this application; rather, it's a summary of the project, and the documentation of the things I learnt—or more aptly, the things I learnt and still remember😅.

The Stack

The core aspects of the project as well as the elements associated with them are summarized as follows:

Programming Language - Python
Backend - Django
Frontend - Django (HTML/CSS and Bootstrap)
Database - PostgreSQL
Hosting - Heroku

You can find the repository for this project on my GitHub. You can check out the application here.

Development

Django uses the Model-View-Template (MVT) pattern which is only slightly different from the general Model-View-Controller (MVC) pattern because Django takes care of the Controller aspect. The Models, Views and Templates are essentially the building blocks of the project as they define how your app functions and interacts with the user.

The Model

The Django model provides an Object-relational Mapping (ORM) to the database. The models you define are mapped to tables in your database and they can all be connected. This URL Shortener App uses a model called Shortener. Its fields are as seen in the snippet below. The save method is called to update the database with the shortened URL associated with the user's original URL.

The Utility Function

An utility function is used to generate the shortened URL as seen below. It checks if the created URL is unique and only returns the generated code once that condition has been satisfied.

The Form

Forms are the receptacles of a user's input and they define the actions and methods (POST, GET) that get sent to the server. The Form class is what handles forms in Django. It accepts specifics such as form fields, layouts, valid values, and so forth. More on that can be read here. Forms can be inherited from Models and that's the road more travelled. It was also the road I took.

Views

The Views in Django are what take a user's web request and returns a response. Two basic view functions were used; one received the user's original URL and returned the shortened link while the other was responsible for redirecting the shortened link to the destination of the original URL.

In defining the views, I also -

defined the logic that monitors the number of times the shortened link has been followed
ensured that shortened links were only created if the user's URL wasn't currently existing in the database. If a record of the URL existed, the shortened URL associated with that record will simply be returned.

Templates

These are files that define the structure of the HTML pages associated with the rendered views. Two templates were used—the base template and the home template. The former defines the general boilerplate html code to be inherited by other more specific templates like the home template. The templates were written in HTML and the Django Template Language. The former reprised its role as the standard markup language for web pages while the latter made it possible to extend templates, insert conditionals, and call URLs associated with the application.

Tests

This was my first experience writing tests for an application. Thankfully, the Django documentation proved really helpful. You can learn more about Django tests here and here. I wrote tests for the forms, models, and views. Below is a snippet of the unit tests written for the forms.

Deployment

The URL Shortener App was deployed using Heroku's free tier cloud service. It was a bit tricky but all I needed to do was follow the documentation as seen here, and it was fine in the end. Heroku is well integrated with git so deploying and even redeploying after making some changes is not so complex.

Furthermore, by default, Django makes use of an sqlite database which Heroku does not directly support. There are a few workarounds to that solves that problem but I ended up using a PostgreSQL database even in my local development environment. I could have done without that, yes. However, I wanted to learn how to incorporate a different database into an application and it was interesting doing exactly that.

Opportunities for Improvement

For the next iteration of this project, I intend to add a couple of functionalities including (and probably beyond):

showing users the links they've created
allowing users delete their created links
dockerizing the application
automating the tests
making the UI a bit better

Lessons

I have categorized the critical things I learnt and the "big" challenges I faced into two; code-related and non-code-related.

Code-related Lessons

These lessons specifically have to do with new approaches to solving problems I discovered (I'm not Christopher Columbus, I know) in the course of this project. Some, you may already know, but are, to me, worthy of note.

Windows Terminal is the Truth

I use a Windows environment and for a long time, Git Bash was sufficient to fulfill my command-line needs. In deploying the application to Heroku, however, I struggled with adding a SECRET_KEY to my application environment. It turned out that the ampersand (&) character which was part of my SECRET_KEY was a reserved character and it was not getting parsed as intended. I was stuck for a few hours trying to find a way around it and I tried different solutions as seen on the web to no avail. Single quotes, double quotes, backslashes, etc. Nothing worked.

Then I decided to change my command-line environment from Git Bash to Windows Terminal and that did the trick. Using a PowerShell profile in Windows Terminal, I only had to wrap the ampersand character—and the close-parenthesis character,")"—in double quotes and the entire string in single quotes to get it to work. Honestly, I'm not quite sure why I stayed away from Windows Terminal for so long but I'll be using it here on out. It's customizable; it can be integrated with CMD, PowerShell and Linux environments; it supports "Ctrl + C" and "Ctrl + V" as the default copy and paste commands unlike Git Bash; and it also looks nice.

Python Decouple for Environment Variables

In the past, I've always approached accessing environment variables by:

creating a JSON file and storing the environment variables therein
writing a a few lines of code in my settings.py file to read the JSON file
accessing each variable in the JSON file

However, in the course of this project, I picked up on using the Python Decouple library to access my secret keys. Once installed with pip, I only needed to:

create an .env file and store the environment variables
import the config object from decouple in my settings.py file
access each variable in the .env file

In both methods, it is necessary to include the JSON and .env files in a gitignore file. However, the latter is a lot quicker to implement than the former as it saves me a couple of lines, and going forward, it is definitely the way to go.

Non-Code-related Lessons

These lessons aren't particularly linked to code but they were important things to note.

Sometimes, it is okay to fail a test

If you'd told me in high school that I'd one day look forward to failing a test, I would have punched you in the face to snap you out of that illusion. Okay, maybe that's going a bit too far but you catch the drift. Being optimistic and more so, delighted about a failed test is not exactly a "natural" emotional state.

However, while writing tests for this URL Shortener App, some were specifically designed to fail. The successes of these tests were hinged on their failure. The tests had to fail for them to pass, for lack of a less ironic expression. This was for me, a rather poignant reminder that failure is not inherently a bad thing. For all the stigma and unenviable disrepute it continues to garner, failure, sometimes, is okay.

Front-end isn't bread and butter

"It's just styling". Eh, no it's not! At least not for me. Giving the URL Shortener App a good interface wasn't the easiest of things for me. From the layout and the elements to the fonts and colors, it was a bit difficult. I refer more to deciding on what to do rather than the implementation. For instance, choosing the color scheme for the site was a bit frustrating. If you think my final decision isn't so good, wait till you see what my many iterations looked like. For this bit, I'd appreciate any resource or tips that could help improve the choice of colors and page styling in general.

I have a thing for this thing called `Code`

I thoroughly enjoyed building this App. I'm not exactly a code newbie but I'm green to Software Engineering, and it is, for me, an exciting frontier. I look forward to building even better products, and learning from and collaborating with other Engineers.

Thanks for reading!

Let me know what you think about this URL Shortener App!

Also connect with me:

LinkedIn: Wolemercy
Twitter: Wolemercy