Ten percent of nothing is, let me do the math here…

I’ve been seeing commercials about the Mountain Dew “Every 2 Minutes” thing for Xbox One, so I looked at how it works today. If I understand correctly, the “Every 2 Minutes” refers to auctions where you can win by bidding points that you get by entering codes you get from Mountain Dew and Doritos. There’s also a daily sweepstakes that you can enter with entries that you earn from those same codes. It looks like there are fifteen or so sweepstakes left at this point.

I’ve already got my Xbox One preordered, and I’ve mostly stopped drinking Mountain Dew, so the contest itself isn’t that interesting to me, but I was interested in how one might maximize the chances of winning. This is what I do during my lunch hour… statistics. That’s why I’m cool.

Let’s say that there’s only one other entry in each sweepstakes, and that I have fifteen tickets to put into whichever sweepstakes I want.  If I put them all in one sweepstakes, I have a 15/16 shot of winning, or 93.75%.  If I spread them out so that I put one in each entry, I have a 1/2 (50%) chance of winning in each sweepstakes.

From that, it sounds like I’m better off putting all my eggs in one basket, so to speak, but I don’t think that’s the case. I have a 50% chance of losing each sweepstakes, but there are 15 sweepstakes.  The chance that I lose every sweepstakes is 50%^15, or 0.00305%, which means that spreading my entries out gives me a 99.997% chance of winning… at least once (see the image above).  There’s also a chance that I could win multiple times, which means that spreading my entries out gives me a better shot at winning and gives me a shot at getting more than one Xbox One.

The benefit of entering in multiple sweepstakes seems to hold true when more people are entering, as well, though the benefit is somewhat lessened in this situation (0.14978% vs 0.14988% at 10,000 entries – see image). I’m still assuming that there’s an equal number of entries in each sweepstakes, but I honestly have no way of knowing if that’s true.

The takeaway from all this is that statistics are fun the old proverb is right, and you shouldn’t put all your eggs into one basket.


One goes into the house of eleven eleven times, but always comes out one

Optimus Prime

AFTER A BRIEF HIATUS, I’m going to continue my study of C#, and I’ve decided that I needed some small projects to work on to practice with C#.  For now, at least, I’m going to work my way through Project Euler. Project Euler is described, on its website as “a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.”

I’m not entirely concerned with finding the most elegant, efficient method for each problem, but I do plan to write and share code to work each problem, until I a.) get stumped, b.) get bored, or c.) find another project to practice programming on.

Before I get started working the actual problems, though, a quick glance at the project list shows that a lot of the problems are related to prime numbers. I don’t think C# has a function specifically for determining if a number is prime, so I’ve decided to write one. I did a quick search to see if there was a built-in function, and all I found were custom-written ones. I tried not to look at those, specifically for the purposes of writing my own here.

Here’s what I came up with:

public class transformer
  public string name;
  public string transformMode;
  public string affiliation;
  public string state;
  public bool hasMatrixOfLeadership;

  public transformer(string name, string transformMode, 
                               string affiliation, string state = "Robot", 
                               bool hasMatrixOfLeadership = false )
    this.name = name;
    this.transformMode = transformMode;
    this.affiliation = affiliation;
    this.state = state;
    this.hasMatrixOfLeadership = hasMatrixOfLeadership;

  public void transform()
    if (this.state == "Robot")
      this.state = transformMode;
      this.state = "Robot";

  public bool isPrime()
    return hasMatrixOfLeadership;

Continue reading

Robert B. Parker’s Lullaby by Ace Atkins

Robert B. Parker's Lullaby coverI TRIED, FOR A WHILE, to come up with a reason why Robert B. Parker’s Lullaby, by Ace Atkins, was technically Science Fiction. Spenser, Parker’s most famous lead character, had, after all, survived the death of his universe’s creator. He’s still middle aged, even though he’s been active as a detective for decades. In the end, though, it occurred to me that this is my blog, so if I wanted to expand its scope to include books and movies other than science fiction, I could do so. So, I did.

Though a couple of Spenser novels have been published since Parker’s death, those were novels he had written, published posthumously. Lullaby, on the other hand, is the first book written by the successor chosen by Parker’s estate, Ace Atkins. Atkins was already an established author of mystery novels, having written a series of books about his own creation, Nick Travers, as well as several stand-alone novels.

Quick review: While Spenser fans will undoubtedly feel that something is missing in Atkins’s portrayal of the detective, the book is a worthy addition to Spenser canon. I’ll continue to pick up books in this series, confident that I’ll enjoy them while continuing to miss Robert Parker. I think I’ve also been persuaded to give Atkins’s other books a try.

A more detailed review below…
Continue reading

I’d say his chance’d be about one in… a very large number.

Goat Eye picture from Wikimedia CommonsSO, THE ONLY COMPONENTS I really have to attach to my Netduino are LEDs at this point. I’m waiting to get some new stuff from Sparkfun, but, for now, my Netduino projects are all pretty much the same. So, this post is all about programming.

A few years ago, a couple of friends and I went out of town for my bachelor party. Being the wild men that we are, we spent a good portion of the evening arguing about The Monty Hall Problem. Despite the fact that I was provably correct (as you will soon see), my friends utterly refused to listen to me.

The basic problem is this: Suppose a game where one of three options (“doors”) is the winner. The other two doors have a goat behind them (or some other effectively useless prize). The player picks a door, then the host of the game opens one door that the player did not pick. The host of the game will never open the winning door. After this door has been revealed, the host will give the player one chance to switch his or her chosen door.

Should the player switch, or not?

Most people (myself included) will immediately jump to the conclusion that each door has a 1 in 3 chance of being the “correct” door, and that switching will not, therefore, provide a significant boost in one’s chances of winning. My friends took that position in our argument. Further examination of the problem, though, will show that switching does, in fact, increase one’s chances, doubling the chances of winning.

The code I wrote runs a total of 1500 simulations (this is easily changed by changing the value of the “numReps” variable) where “my” pick and the winning door are chosen randomly. Since “Monty” will never choose to open the winning door or my door, his choice is only truly random in the event that those doors are the same.

Quick side note: When I was writing the code below, I was on a computer that did not have Visual Studio C# installed. It did, though, have the Microsoft .NET framework. This was compiled using the CSC.exe compiler included with the Framework.

After five runs of the code, my results are:

  1. Switching wins 1001 of 1500 simulations.
  2. Switching wins 976 of 1500 simulations
  3. Switching wins 1026 of 1500 simulations
  4. Switching wins 989 of 1500 simulations
  5. Switching wins 988 of 1500 simulations

Of 7,500 simulations, switching was the preferred option 4,980 times, or about 66.4% of the time. Since this is a random (or, at least, mostly random) simulation, we can see that switching is better than staying put by a statistically significant amount.

using System.IO;
using System.Windows.Forms;

public class TheMontyHallProblem

	static public void Main()
		int MyPick, Winner, MontyOpens;
		int switchWin, switchLose;
		Random assign = new Random();
		int numReps = 1500;

		switchWin = 0;
		switchLose = 0;

		for (int i = 1; i

Okay, we’ve seen the simulation, and its results. Why does switching help?

Because of the sentence I highlighted above: Monty will never open the winning door.

Two-thirds of the time, the player will choose a losing door. In this case, Monty will always reveal the other losing door, so two-thirds of the time, the player is given the option to switch to the winning door. The remaining one-third of the time, the player has chosen the winning door, so switching will not help the player out.

Since the player has no way of telling which of the above scenarios is true, but switching will win 2/3 of the time, the player should always choose to switch.

You got the light from the console to keep you


LED Photo by PiccoloNamek (Wikipedia User)


I STARTED WORKING PLAYING with my Netduino a few days ago. Since I was just getting started (and I don’t have any motors or anything anyway), I tried something simple. Lighting up and changing the color of an RGB LED. The initial program technically worked, but it didn’t really work well. The color changes were often abrupt, and the algorithm I was using to cycle through colors led to the LED going dark quite often, sometimes for several seconds at a time. One iteration of the software even had multi-minute LED blackouts. The only reason I realized the LED hadn’t just shut off altogether was that it came back on while I was studying the code.

Anyway, this project isn’t really anything to brag about, and I likely wouldn’t post about it at all, except that it’s the first program that I really feel does what I want it to. Also, I created a class for the RGB LED that made changing the colors a little easier, and I’m pretty pleased with that one, so I’d like to share it.

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace ColorChangingLED
    using System;
    using Microsoft.SPOT.Hardware;

    class Program

        public class rgbLED
            public rgbLED(Cpu.Pin RedOut, Cpu.Pin GreenOut, Cpu.Pin BlueOut)
			    // The Pins are all set by the constructor.
			    //  Red, Green, and Blue uints CAN be set here, but
			    //  otherwise will default to zero.
			    this.redPin = new PWM(RedOut);
			    this.greenPin = new PWM(GreenOut);
                this.bluePin = new PWM(BlueOut);


            // These will be used to set the duty cycles of the individual pins,
            //  governing the color output on the LED.
            public uint Red = 0;
            public uint Green = 0;
            public uint Blue = 0;

            // Specific individual pins...
            private PWM redPin;
            private PWM greenPin;
            private PWM bluePin;

            public void HSV(double hue, double saturation, double value)
                // Convert HSV to RGB and set LED appropriately.

                // This method doesn't really do anything at this point.
                //  It will, though...
                // Formulas to convert HSV to RGB will go here.  

                // Then set the led to display the new color.
                // Set the uints Red, Blue, and Green.
                //this.Red = ;
                //this.Green = ;
                //this.Blue = ;

                // Set the uints Red, Blue, and Green.


            public void RGB(uint r, uint g, uint b)
                // Set the uints Red, Blue, and Green.
                // Then set the led to display the new color.

                this.Red = r;
                this.Green = g;
                this.Blue = b;

        static void Main()
		    // Initialize our LED (NOTE: on the Netduino, 5, 6, 9, and 10 are the only PWM pins)
            rgbLED RGB1 = new rgbLED(Pins.GPIO_PIN_D5,Pins.GPIO_PIN_D6,Pins.GPIO_PIN_D9);

		    // Declare our color values (doubles are used instead of uints to add some variation)
		    double red, green, blue;

		    // Declare the "bandwidth" variables that will decide how much change each color gets.
		    double redBW, greenBW, blueBW;

		    // Initialize a random.  We'll use that shortly.
		    Random rand = new Random();

            // Set initial values.
		    red = 10.0;
		    blue = 10.0;
		    green = 10.0;
		    redBW = 0.5;
		    blueBW = 2.1;
		    greenBW = 4.8;

		    for (int i = 0; i < 1000; i++)
 		    { 			    // Step each of our color values up (or down, if the BW value is negative)
 			    red += redBW;
 			    blue += blueBW;
 			    green += greenBW;
			    if (red > 100.0) // If our value is out of range, reset.
                                    red = 100.0;
                                    redBW = -1.0*((double)rand.Next(50)) / 40;
                            if (red < 0.0)
                                    red = 0.0;
                                    redBW = ((double)rand.Next(50)) / 40;
			    if (green > 100.0) // If our value is out of range, reset.
                                    green = 100.0;
                                    greenBW = -1.0*((double)rand.Next(50)) / 40;
                            if (green < 0.0)
                                    green = 0.0;
                                    greenBW = ((double)rand.Next(50)) / 40;
			    if (blue > 100.0) // If our value is out of range, reset.
                                    blue = 100.0;
                                    blueBW = -1.0*((double)rand.Next(50)) / 40;
                            if (blue < 0.0)
                                    blue = 0.0;
                                    blueBW = ((double)rand.Next(50)) / 40;


            RGB1.RGB(0, 0, 0);

Like Something Out of Science Fiction

Hello, World!

Hello, World!

READ A LOT OF older science fiction stories, and something stands out. The future technology that they assumed we would have by now (or even much farther in the future)? We have most of it now. Computers are everywhere, in everything. I can carry hundreds of books with me everywhere I go, and get new books pretty much anytime I want simply by clicking a few buttons. The cell phone that I carry in my pocket uses a processor that runs (more or less) a thousand times as many calculations per second than the guidance computer that took the Apollo 11 to the moon. Even after a lot of music, a couple of videos, and more than a few apps, its free memory is more than twenty times the size of the hard drive in my first computer, which was only…

Never mind how many years ago that was, actually. The point is, we live in an amazing time.

All of that is to preface this. I just picked up a new hobby, tinkering with the Netduino. So far, I’ve only built a small circuit and program on a breadboard to light a series of LEDs, but I hope to use this to learn a little more about C# – we used C and C++ a little in college – and, selfishly, I want to build some fun toys to play with. That is, for my nephews to play with.

I just picked up a hobby where, if I actually stick with it, I could build robots.  It’s not like I’m building a warrior robot race one laser gun at a time, but still… robots!

I’m going to use this blog to document my progress on any projects I start, including any C# programs (or pieces of programs) that I find interesting. Since my day job involves a lot more Visual Basic, some VB code will likely pop up here and there, too.