Continue reading "Probability teaser 1 – the Monty Hall problem"

The post Probability teaser 1 – the Monty Hall problem appeared first on Vegaskid’s net.

]]>I recently posted the following teaser on Twitter:

Teaser of the week:

You have 10 doors to choose from, 1 has a car behind, the others have a goat. You choose 1. I then open 8 of the other 9 doors to show a goat. What is your chance of winning the car if you switch from your chosen door to the last remaining one? #nocheating

— Matt Thompson (@Vegaskid1973) March 9, 2018

This is known as the Monty Hall problem, named after the game show host.

When I first read this problem, my brain initially told me that my chances were 50/50, whether I stuck with my first door or switched to the only other closed door. Of course, I’m a bit of a natural sceptic and so I had this niggle in my head that said 50/50 was too obvious. So off I went to read up on the problem.

A number of people responded to my tweet. Most thought it was also a 50/50 chance even when I tried, in a limited stutter of 280 characters, to explain the real answer. One person said it would be higher than 50/50 but they couldn’t remember the maths and only one person gave the correct answer, so let’s see if we can get there together.

Let’s begin with just three doors.

? ? ?

One door has a car behind it, the other two have goats. Your chances of picking the car is 1 in 3, 1/3, 33.3% to use various measures. I will use a probability measure of 0.33… which is on a scale of 0-1. If you add up all the probabilities of events that can happen, they will add up to one. You can only pick the car or a goat. There are no other options. Therefore, the chances of picking a goat are 2/3, or 0.66…. This can be calculated as 1-0.33…

(Note, for numbers that are recurring, I am using two decimal places with the … notation)

The doors can be setup before the game as below, G=goat, C=car:

GGC

GCG

CGG

Remember what happens when you pick your door? Monty will open all but one of the other doors to reveal a goat, so you end up with your chosen door and one unopened door. So one of two situations can happen here.

- You pick the car 1/3 of the time and the other door will always be a goat
- You pick a goat 2/3 of the time and the other door will always be the car

The teaser asks, what is your chance of winning the car if you switch doors. Therefore, 1/3 of the time when you switch, you lose (or win if you prefer goats) and 2/3 of the time when you switch, you will always get the car. So no 50/50 here.

OK, the last section started with the basics using just 3 doors, but my question was with a game using 10 doors. Let’s use the same process but update the numbers accordingly.

? ? ? ? ? ? ? ? ? ?

One door has a car behind it, the other nine have goats. Your chances of picking the car is 1 in 10, 1/10, 10% to use various measures. I will use a probability measure of 0.1 which is on a scale of 0-1. If you add up all the probabilities of events that can happen, they will add up to one. You can only pick the car or a goat. There are no other options. Therefore, the chances of picking a goat are 9/10, or 0.9. This can be calculated as 1-0.1.

Remember what happens when you pick your door? Monty will open all but one of the other doors to reveal a goat, so you end up with your chosen door and one unopened door. So one of two situations can happen here.

- You pick the car 1/10 of the time and the other door will always be a goat
- You pick a goat 9/10 of the time and the other door will always be the car

The teaser asks, what is your chance of winning the car if you switch doors. Therefore, 1/10 of the time when you switch, you lose (or win if you prefer goats) and 9/10 of the time when you switch, you will always get the car.

So…*always, always switch!*

OK, sometimes people like to see this in action and so I’ve created a Python script here that simulates the game. Please don’t troll me too much for the lack of Pythonic code, although I welcome constructive feedback! Hopefully the code is commented well enough for you to see what it is doing.

I’ve always loved probability and statistical type problems because they are great examples of using pure mathematics to challenge people’s assumptions and biases. Hopefully, you found this example clear. If not, let me know so I can improve upon it.

Till the next time.

The post Probability teaser 1 – the Monty Hall problem appeared first on Vegaskid’s net.

]]>Continue reading "The truth about Boolean values in Python"

The post The truth about Boolean values in Python appeared first on Vegaskid’s net.

]]>George Boole was an English mathematician who is credited with having invented a branch of algebra in which an expression is evaluated to one of the truth values, true or false. Unsurprisingly, this became known as Boolean algebra (I’m hoping that Thompsonian snark will be a thing in the not too distant future).

This post looks at how all objects in Python can be tested for a truth value and what that means.

In Python, you can assign True or False to any variable.

# Assign True to a, and False to b a = True b = False a True b False

That’s all well and good and is very useful if we want to have a binary type value to assign, rather than trying to use 0’s and 1’s, ‘yes’ or ‘no’ etc., which could cause confusion with your code where you also use those values for other purposes e.g. it probably doesn’t make sense to have 5 -5 = False.

Additionally, in Python, any object can be tested to see if it is truthy or falsy. What does that actually mean? Take a look at the following code:

if foo == 5: bar() if foo: bar()

A nice and simple example but for beginners to Python, the second if statement might cause confusion. Initially, let’s confirm we understand the first if statement; if the foo variable refers to the value 5, that branch runs i.e. bar() is called, if not, that branch is skipped.

What about the second example. What is if foo: doing? This is where Python tests the truthiness or falseness of the foo variable. In short, that statement means if foo is truthy, run that branch, if it is falsy, skip that branch. So bar() will only be called if foo is truthy.

So what determines if something in Python is truthy or falsy? It depends on the type being evaluated. The table below lists the main types within Python. Remember that these are all objects in Python. (Some other languages consider data types such as strings and tuples to be primitives.)

Type |
When is it truthy? |
When is it falsy? |

str | Not empty | Empty, ” |

list | Not empty | Empty, [] |

tuple | Not empty | Empty, () |

set | Not empty | Empty, set() |

dict | Not empty | Empty, {} |

int | Not zero, 0 | Zero, 0 |

float | Not 0.0 | 0.0 |

bool | True | False |

NoneType | Never | Always |

Function | Always | Never |

Class | Always | Never |

Let’s go back to that second if statement.

# If any one of the following assignments are used, with the others # commented out, 'if foo:' will evaluate to True, based on the # truthiness of foo and so that branch will be executed foo = 'spam' # str foo = ['spam', 'eggs'] # list foo = (spam, eggs) # tuple foo = {5, 4, 3, 2, 1}# set foo = {'dead': 'parrot'} # dict foo = 42 # int foo = 3.14 # float foo = True # bool # Function and class examples shown later if foo: bar() # The difference between something being truthy and something being # True should be pointed out here for further clarity. The syntax # below checks that foo is a Boolean value, True if foo is True: # However, the syntax below checks if foo tests as being truthy. So # that not only includes foo = True, but also foo = 'hello', # foo = 15 and so on as per the table above. if foo: # PLEASE NOTE, PEP8 PREFERS THE if foo: SYNTAX IN ANY CASE

There is a really handy built-in function we can use to tell us if something is truthy or falsy, the bool() function.

foo = 5 bool(foo) True foo = 0 bool(foo) False # To test the other types in the table, we need to # create a function and class def test: pass bool(test) True class Test: pass bool(Test) True # And finally, the NoneType, which will always test as False bool(None) False

This post began discussing the True and False Boolean values you can assign in Python and then went on to discuss how all objects in Python can be tested for a truth value and what that means. I hope this has been useful.

Till the next time.

The post The truth about Boolean values in Python appeared first on Vegaskid’s net.

]]>Continue reading "We need more mentoring in IT"

The post We need more mentoring in IT appeared first on Vegaskid’s net.

]]>In an earlier post on strengths and weaknesses, I briefly talked about a general lack of mentoring in IT. Having given this some further thought, I thought I’d tease out some more salient points on the topic.

I like the following definition of mentoring so will be basing my post on this:

Mentoring is to support and encourage people to manage their own learning in order that they may maximise their potential, develop their skills, improve their performance and become the person they want to be– Eric Parsloe, The Oxford School of Coaching & Mentoring

The diagram below (FYI, produced in PowerPoint thanks to this great little video) broadly represents the distribution of knowledge in our wonderful field of technology.

Note the following observations:

- Nobody knows nothing
- Nobody knows everything
- There is a certain level of knowledge at which the numbers drop off steeply
- There is a clear grouping near the middle
- The graph also provides a reasonable model of the speed at which people acquire knowledge. The y-axis represents that speed

The first two points are worthy of further discussion:

Point 1 essentially means that everybody has something to teach somebody else.

Point 2 is the same as point 1 but flipped on its head. Everybody can learn something from somebody else.

Yet the theme of this post is that there is a lack of widespread mentoring going on in IT. By that, I simply mean that it is far from being the norm and would benefit from serious improvement.

If you work somewhere that encourages people to mentor others (which is lovely!), it is likely that the people who sit towards the right of the graph above are mentoring people who fall further to the left. If you are less fortunate, you might find that it is longer serving people mentoring people who are less time-served, which isn’t always useful. Of course, who gets to mentor who might simply be decided by the length of one’s beard, which is wrong for a whole number of reasons, a key one being that some of the most knowledgeable people I’ve worked with are unsurprisingly incapable of growing a beard.

However, one can combine points 1 and 2 above under the following statement:

Anybody with knowledge should be able to mentor somebody without that knowledge– Vegaskid

As well as strengthening people and teams across your business, with all the benefits that brings (happier staff, increased productivity, personal and business growth, innovation, collaboration, etc.), a common business risk is also mitigated i.e. the risk of a ‘key master’ walking out of your company with unique knowledge that nobody else knows. I’ve seen this happen in a number of companies and it puts unnecessary strain on those who stay and can stunt growth, both at the individual and company level, whilst the gaps are filled.

So, having read this far, are you ready to have a think about what you are knowledgeable about and offer to transfer some of that wisdom to somebody else? Or even just to offer support at any level? It needn’t be in a more formal format if that isn’t your style. It could be as simple as emailing snippets of information, or posting to your Intranet. Or writing a blog post to a wider audience. Or simply walking over to somebody’s desk and having a chat about what they are working on.

Businesses should enable and encourage this behaviour and make it part of their culture. Reward people who do it, at the very least by acknowledging it and giving them the time to do it. That is often all that is required.

Beyond our own companies, I would love to see an industry wide movement to help foster a mentoring mindset. A combination of bottom up and top down approaches could really help across the board.

In this post, I’ve deliberately steered well clear of the reasons why people don’t mentor up to this point because in my experience, it usually has something to do with either the culture of the business or individuals having a fear of losing some level of perceived control or worth by sharing knowledge with others.

I think the best way to address starts somewhere in the middle i.e. businesses enabling and encouraging their people to share knowledge whenever they can. The rest is up to you.

Till the next time.

The post We need more mentoring in IT appeared first on Vegaskid’s net.

]]>