I’ve been perusing a pretty good book by Michael McRoberts called “Beginning Arduino”, and after putting together one of the first projects I decided to have fun with it and write some more interesting code than the one provided. The original scheme gave a series of three LEDs that would turn on as if they were a stop light, and then allow someone to press a button to get the light to change to red so that another LED, representing the pedestrian walk sign, could turn on. This wasn’t very interesting to me, so I made it into a reaction game instead otherwise using the same circuit. See the video immediately below, and the circuit diagram (made using Fritzing) and code below the fold.
A few days ago I found myself having a vague recollection of an interesting statistics problem. All I could remember was that it had to do with having a room full of people and the probability that any two people in that room would have the same birthday. I remembered the point, which was that it is much more likely than you might think, but I was fuzzy on the details.
After trying to define the problem and find an answer mathematically, I remembered that I suck at statistical reasoning about as much as the average person. So I decided to model the problem with a short Python script and find the answer that way.
Sure, I could’ve looked it up, but where’s the fun in that?
The problem: There are n people (say, at a party) drawn randomly from a population in which the chances of having a birthday on any day is equal to having a birthday on any other (which is not true of real populations (probably)). What is the probability of there being at least two people with the same birthday in the sample?
To put this thing together, I figure we need three things:
- The ability to generate random numbers (provided by Python’s random module);
- An object representing each person;
- A party object full of those people.
Then we can add things like the ability to choose how many people we want at the party and how many parties to have, as well as some output for making plots!
First, the Person object. All each person needs is a birthday:
import random random.seed() class Person: def __init__( self ): self.birthday = random.randint( 1, 365 )
[2013.02.26 Edit: A number of people are finding this through Google searches. I don’t have an updated post on the topic, but if you’re trying to assemble multiple DNA fragments then I suggest looking into Gibson Assembly. NEB sells* a dead-simple mastermix, which is a bit pricey per reaction (I just make my reactions half the size) but comes out to cheap when you take into account the cost of labor (so long as your PI values your time…).]
I’ve spent the last couple months building a plasmid library, and in the process I thought of a trick. Ligations, perhaps the worst part of cloning, are notoriously finicky reactions. The goal is to take several pieces of linear DNA, where the ends of the pieces can only connect in a certain way, and then use an enzyme (T4 Ligase) to sew them all together into one piece (in my case, a circular plasmid).
I needed to insert three fragments at once into a single backbone. In my ignorance (from my lack of experience) I thought ligating four fragments should work just as well as two, so I just threw them all together and ran the reaction. The result was a mess, and when I tested 40 different clones afterwards not a single one was correct. So I started adding them one piece at a time which, obviously, was going to take three times as long.
I previously showed you (without a screencast) how to make NP++ default in XP. Of course, people have successfully done this for W7/Vista as well, but the various tutorials I saw were all a huge pain in the ass. Except for one: a comment on a more-complicated method. I made the following short screencast to demonstrate that method. This one has the advantages of being easy to reverse, easy to do, and not in any way intimidating!
I also have a post on using regular expressions in NP++, if you’re into that sort of thing.
You’ve all heard this classic statistics problem, based on an old game show:
A contestant is shown 3 doors. Only one of those three doors hides something of value to the contestant (perhaps a new car), while the other two contain nothing. The contestant chooses one door, but that door remains closed. The host then opens up a 2nd door, and this door is always a losing door. At this point, the contestant may choose to now open the originally-chosen door, or switch to and open the last remaining door.
So why is this interesting? It turns out that the way to maximize your chances of winning is to always switch, and this maximized chance is 67%. It also turns out that this is totally non-intuitive, and that most people think that, if the contestant always switches, the chances of winning are at best 50%. If you haven’t heard the solution to this problem before, you should think through it and see what you expect the chances of winning are under the two conditions: After the contestant chooses a door, and is subsequently shown that one of the other two is a losing door,  the contestant always switches to the remaining door, or  the contestant never switches. After the jump, I’ll explain this intuitively and then show a Python script to simulate this problem.