I came across an interesting dice game called “Cubes” (which is essentially a simple version of craps) recently and decided to calculate the odds. This post will be interesting if you have some background in Probability and Calculus. It will be even more interesting if you don’t and are curious to know what these maths can do.
A player of Cubes places a bet and two six-sided die are rolled. If the sum of the die is 7 or 11 the player wins twice the pot. If the sum of the die is 2, 3, or 12 the player loses the pot. Otherwise the number rolled becomes the player’s “point” and the player makes another bet (which goes into the pot with the first bet) and rolls again. If the player rolls his point he gets twice the pot, if he rolls a 7 he loses. The player keeps betting and rolling until he either loses or wins.
The game is interesting because it’s not immediately obvious how the odds work out. Consider the first roll. The player can win with a 7 or 11 which have probabilities:
and lose with a 2, 3, or 12 which have probabilities:
Below is a simple probability table for reference.
Anyway it would appear upon first inspection that your odds of winning are twice as good as your odds of loosing. Very good. But what about when the player rolls something other than a 7, 11, 2, 3, or 12 and it becomes his “point”? In this case the player has a higher probability of rolling a 7 (note this is the most frequent number in the table above) than any of the possible “points” he could have rolled. At this point the game is a loosing battle. However the player started with much better odds of winning outright. So which of these competing forces wins out?
To figure this out we’ll use some basic Probability and Calculus. We wish to determine the probability of winning a game of cubes. To do this we need to sum up the probability of every way in which we can win. If you’re not familiar with the axioms of probability consider a simple example:
Warning: Balls in Urn Example
Imagine you have an urn with red ball, a blue ball, and a black ball of equal size, shape, etc.. You win a prize (penguin) if you draw any two balls from the urn and one is red without looking into the urn. What are the possible combinations?
red blue | red black | blue black
Three different combinations, each equally likely. Two of these will win us a penguin. To determine the chance of winning we simply sum the probability (1/3) of each of the combinations that allows us to win. This gives us 2/3 which makes good sense given two of the three options will win use the penguin
Back to the game of Cubes. Now just as in the urn example we must sum up each of the possible ways (or events) in which we can win the game. We already know one event that will lead us to win: rolling a 7 or 11 during the first round (with a 2/9 probability). Now we just need to figure out the remaining ways we can win and add them up.
The only other way we can win is by rolling our “point” before a seven. To get to a point round in the first place we must not have one outright and not have lost out right. Let’s consider the event where we get to the point round by rolling a 5 and win:
Here we have the probability of getting to the first point round multiplied by the probability of rolling a 5. This event constitutes a win, so we’ll add to to our sum. Let’s generalize a bit and call the probability of rolling our point (in this case 5) q. We’ll also expand the idea such that we capture the case where we roll our point after one failure, two failures, etc.:
Where the new term in brackets is the probability of not rolling your point or a 7 (which allows the player to move to the next round). Note this term’s exponent increases by one each turn as the player must continue to not roll his point or a 7. This series is infinite as it’s possible for the rolling to go on forever. Let’s make it look nicer:
This is a geometric series with a closed form solution. I’ll leave the proof of the closed for solution and the algebra to the reader. We end up with a very clean result:
We’re almost done. We’ve accounted for an infinite number of rolls events that lead up to a win but for only a single value of q. We need to adjust this solution slightly such that it accounts for the different possible point values a player could roll and their corresponding probabilities. It turns out we only need to worry about three values of q since 4, 5, 6 and 10, 9, 8 have the same respective probabilities. We multiply each of these possible values of q with the probability that we rolled that point value. For example a player could roll a 4 or a 10 with a probability of 6/36 = 1/6 which would give us a q value of 3/36.
This give us 0.4929292…. It’s actually quite remarkable this game is so close to fair. In any case over a large number of trials we expect to loose. Not a good bet, but a great analysis.
This list served as an interlude to a presentation I gave recently.
- SQL – Most boring / useful
- PL/pgSQL – wtf is this? I have to write database functions in this?
- Bash – Useful and fast. Nobody knows how to write in this.
- C – God. Dangerous. Caused heartbleed bug. Bad language! ::Language runs off::
- Matlab – haha
- Perl – Madness. Fast.
- Ruby – For hipsters / designers. Slow but sexy.
- Mathematica – Designed to clash with every other language’s syntax
- Java – enterpriseCodeThatMakesYouWishYouWereDead (deprecated)
- PHP – [censored]
- Julia – Smart, Sexy, Fast. Innate parallelism.
- Scala – So many features / idioms it pretty much guarantees a month of 12 hour days before you can read more than 50 lines in a row.
- R – Makes $. Errors and warnings written by devious children.
Recently my 2008 Mabook Pro died. Although I ended up fixing it as documented in this HOWTO I had been searching for a new laptop anyway and this was just the catalyst I needed to make a move. After some searching I came across the Lenovo W line. The machines appeared to be built tough, pack plenty of power, just light enough to carry around on occasion and support Linux fairly well. I settled on the W530 with mostly stock specs and an upgraded full HD screen.
Out of the box the machine runs really well. I’ve played with Arch, Archbang, and Ubuntu and everything is (of course) quite snappy. The only real issue with this machine is its graphics card, which runs Optimus technology; a poorly named feature that means: “optimal use of graphics card considering battery life”. Essentially software will decide when to turn on the power hungry NVIDIA discrete graphics card. I spent many hours trying to figure out how best to setup Linux to use the graphics card in this machine. Hopefully my thoughts will save you some time or aid in your decision to purchase or not purchase this machine.
On the W530, you may select whether you wish to use the discrete, integrated, or optimus graphics in the BIOS. This is a great feature of this machine, and although you might expect that its availability is ubiquitous among laptops, some of the forum postings I have read lead me to believe that this is not the case. Anyway on the W530 we can avoid configuring and installing anything related to Optimus simply by selecting either the NVIDIA “discrete” graphics card or the Intel “integrated” graphics.
If Optimus technology is desired, there is an open source project called Bumblebee that will allow you to start applications so that they use the discrete graphics card (in this case you would select Optimus in the BIOS). Installation instructions are available for most major Linux distributions. On Ubuntu I was easily able to start Minecraft in this manner.
Now for the quirks:
1. The Nouveau open source graphics card driver does not offer OpenCL support (and will fall back to software rendering) for the NVIDIA series code named “Kepler” which includes the K1000M and K2000M, one of which is included in the W530. See the Feature Matrix.
2. The NVIDIA proprietary drivers work quite well (and include OpenCL support) unless you are running Kernel 3.10. This is not an issue for many distributions but is causing a serious headache for Arch Linux and other users on bleeding edge Linux distributions. See the Arch Linux forum post and the NVIDIA forum post. NVIDIA claims this issue will be resolved on the next driver release.
3. The VGA output is wired into the discrete graphics card, which means you must be running this card to use multiple monitors.
The last quirk I never got to the bottom of. I observed that when I ran the graphics in Optimus mode under Ubuntu I *could* use an external monitor, but the screen settings were hard to nail down and the cursor left a trail behind it. In any case it felt clumsy so I didn’t investigate further.
Given these quirks, what is the result? For my use case, I will never need to use an external monitor without a power source, so selecting discrete graphics at start up is fine. When I am out I can use Bumblebee, although I have not found a real need as I rarely employ graphics intensive applications. I use Ubuntu and Arch, and for now will be booting Arch with the integrated graphics. Sooner or later either NVIDIA will fix the issue or Nouveau will support OpenCL.
All in all this is an amazing machine. I am most impressed by the build, as nice specs are not hard to come by. Its screen is beautiful, Its keyboard has a great feel and has 3 back-light settings, and the laptop as a whole is highly upgradeable. If you can deal with a few graphics card quirks this is a stellar Linux laptop.
A little over a month ago I put my Spring 2008 Macbook Pro to sleep and it never woke up. For anyone that works with computers for a living this is quite devastating. This standard level of devastation was amplified by the loss of my Saturday afternoon habitat of streaming tennis matches on the Macbook. About 4 hours later my girlfriend broke up with me over text message, which really threw salt in the wound. Tough day.
I did some troubleshooting and quickly realized the logic board was toast. The tell tale sign here is that if you remove the RAM, the firmware will beep at you on start up. No beeps, no firmware, your logic board is in trouble. Note this is not the first time my Macbook has had issues. Check out this trackpad failure post which includes *more ranting*.
Relationships can be fixed and so can your Macbook. There are a few things that may have happened to your board, most of which involve solder cracking due to high temperatures. If you believe this to be the case and you have a Macbook Pro from the Spring 2008 era, you might try bringing your board to an even *higher* temperature to re-solder everything back into place.
1. Remove the logic board from your Macbook Pro. The instructions vary by model and can be found on ifixit. Make sure to peel off any stickers, those little plastic screw guides, the bumpers on the ports, and clean the thermal paste off of the chips.
NOTE: I tend to use whatever I can to get a job done. In this case that meant using incorrectly sized screwdrivers. This is one situation where being a hack caused me some real trouble, and I highly recommend you buy exactly the sizes you need. Ifixit lists the tools you require and these can probably be obtained at your local Home Depot.
2. Inspect your oven for cakes, pies, and roasts. Remove these.
3. Mount your logic board on some aluminum foil elevated above a baking sheet to avoid direct contact. I made a few half inch balls of foil, placed them on the baking sheet, and then put a sheet of foil on top. This ensures the logic board does not touch the (soon to be) very hot baking sheet. Also consider making a little cup of foil and dropping some solder in. This will act as your “canary”.
4. Preheat your oven to 375 degrees F.
NOTE: My oven is a very non-digital natural gas based device, so your crappy oven will probably work too.
5. Set a timer for 7 minutes and 30 seconds. Place the logic board on the middle rack and start the timer.
6. When time is up remove the logic board. If the solder in the cup has melted, you’re probably good to go. If the board is on fire you can skip to step 12.
7. Let the board cool off for 10 minutes. Have a beer.
8. Put your Macbook back together, making sure not to forget the thermal paste.
9. Take your Macbook back apart and put the little plastic screw guides that you forgot back on the logic board.
10. Put the Macbook back together. Really you can leave the topcase off with just the ribbon cable connected if you like. Probably not a bad time to ensure the fans still work.
11. Press power. Hopefully everything will start up!
12. Begin researching new laptops as this fix has been reported to only last ~4 months and Apple isn’t cool anymore anyway. I recommend the Lenovo W530 with Arch Linux.
This article will teach you how to interface your Crazyflie with a proximity sensor. It would be wise to test your Crazyflie and the proximity sensor before soldering everything together. A detailed account of my experience can be found here.
Bill of Materials
- Crazyflie nano quadcopter (you can also use the 6-DOF version)
- LV-MaxSonar-EZ0 ultrasonic proximity sensor
- Solid wire capable of supporting a 5 gram sensor
- Soldering equipment
1. Solder the proximity sensor pins -> to the Crazyflie expansion header (check out the reference):
+5 -> pin 20
GND -> pin 19
AN -> pin 14
2. Position the wire so the proximity sensor stands straight up, and the eye points towards the front of the copter as shown in the photo.
3. Download the firmware binary.
Clone my fork of the crazyflie-firmware and make the project if you have your development environment setup:
4. Flash the Crazyflie firmware over the radio. Instructions can be found here.
5. Add the vProx logging parameter to your selecting logging parameters and restart the Crazyfly Client
6. Fly around and watch as the Crazyflie detects objects in the Plotter tab!
Recently I was loading a large (~420mb) CSV file for Kaggle’s Adzuna job salary competition into R and ran into some speed problems. Specifically R was crunching endlessly and my Macbook pro turned into a paper weight. It was probably naive of me to attempt loading a CSV of such size into R, but I assumed some well written functions in C would handle this quickly and not block the rest of my processes (actually it didn’t block them but it may as well have). Anyway for the most part I load data into R via ODBC so I figured I’d throw the data into a local PostgreSQL database and get on with my data munging.
However, OS X didn’t want to play ball. Apparently, some big cats ago, Apple decided ODBC wasn’t super important (?!) and decided to remove it from the stock install (I recently upgraded to Mountain Lion so my mac would run slower and sometimes fall into an infinite loop during startup). I searched around a bit and found the usual ODBC suspects that I could install on OS X but quickly recalled the small pains I dealt with doing the same thing with my Ubuntu machine at work. Anyway I played around with ODBC for a bit and wasn’t really getting the optimal configuration I wanted so I looked a little further and found RPostgreSQL.
Now, having used RODBC over the years I don’t have many complaints except that if you don’t already have a stock ODBC install setting everything up can take time from your cause (fun data analysis in this case) that you generally don’t really have to spare. What would be better is a package that’s wicked fast and a configuration that’s handled during package install. Check out the CRAN entry.
After installation I loaded the entire CSV into R in about 3 seconds:
drv <- dbDriver("PostgreSQL")
con <- dbConnect(drv, db="postgres", user="postgres");
rs <- dbSendQuery(con, statement = "select * from rev1");
df <- fetch(rs, n = -1);