# Monthly Archives: June 2011

## Changing the Rules

Years ago I used to run around the neighborhood with the local kids and play some variant of “guns:” cowboys and Indians (we weren’t racially sensitive), cops and robbers, spacemen versus other spacemen. Even though most of us were on board, there was always that one kid who just had to bend the rules a bit.

“Hey,” you’d yell, blowing imaginary smoke off the barrel of your plastic revolver. “I shot you!”

“Nuh-uh,” he would always return. “I was wearing a bullet proof vest.”

I understand now, after a hasty Wikipedia search, that bulletproof armor did in fact exist during the 19th century—at least as far as Wikipedia claims. According to the article, it existed some 300 years before the Civil War. But as kids, we and the bulletproof wannabe thought of ballistic vests in the more widely recognized, modern sense. As far as we were concerned, he was cheating, arbitrarily changing the rules when the game was already in progress.

I always look back on my body armor memories and smirk when something completely new and unexpected comes along to shake things up. (By the way, My Body Armor Memories would make a great band name. Feel free to use it.) In the case of programming that game-changer was decimal numbers, referred to in computer parlance as floating point numbers. As far as your computer is concerned, writing floating point numbers is hard. The mechanics of why this is the case are a bit obnoxious, but suffice it to say that when you see 0.1 on your computer screen, the computer isn’t thinking of the same number. If I assign the number 0.1 to the letter x, then tell Python to print x, I’ll get a nice, pretty 0.1. If I tell it to print 0.1 to 25 decimal places, though, I get 0.1000000000000000055511151. This difference of numbers can cause major trouble in coding if you’re not aware of it, and just like my cheating neighbor, it caught me completely off guard.

In trying to program the opponent creator, I designed a system that checks the time an event is scheduled to occur against the user’s current time. If the two numbers match, a sound is played, and the user can edit events. When I tried to move a tenth of a second at a time, however, I found that my comparisons weren’t matching up. I tried to debug the code with print statements, and things looked like they should have worked.

position 2.8
position 2.9
position 3.0
position 3.1
Event placed!

Even when I pressed the right arrow, then pressed the left arrow to return to 3.1, things looked like they were working.

position 3.2
position 3.1

But at 3.1, I should have received a message that said “sound method called.” I didn’t, and the reason, as I discovered after 8 days of struggling with the code and obtaining tips from experienced programmers, was those blasted floating point numbers. A simple print-out of the three punches I had entered shows why.

{3.1000000000000014: {‘punch’: {‘strength’: 0, ‘height’: ‘head’, ‘can_stun’: False, ‘can_break’: False, ‘speed’: 1, ‘side’: ‘left’}},
2.1000000000000005: {‘punch’: {‘strength’: 0, ‘height’: ‘head’, ‘can_stun’: False, ‘can_break’: False, ‘speed’: 1, ‘side’: ‘left’}},
1.0999999999999999: {‘punch’: {‘strength’: 0, ‘height ‘: ‘head’, ‘can_stun’: False, ‘can_break’: False, ‘speed’: 1, ‘side’: ‘left’}}}

When I enter a check between the time of an event and the user’s current time, they will never match up, because in no world is 3.1 equal to 3.1000000000000014. But completely unaware of this oddity in computer programming, I scanned through my code perhaps a dozen times, grew incredibly frustrated, and even considered a complete re-write. As Christopher Toth later told me, “This is the kind of thing that makes perfectly sane programmers gibber in fear.” How right he is.

The code is working properly now. I found I could overcome the problem by rounding the floating point numbers I encounter, but the solution was a long time in coming. I never realized when I started out that some of the hurdles I would face in learning to program would require a grappling hook and a spotter to overcome. (This situation also shows why I do not give release dates or accept pre-orders.) Even so, the trial is passed, and I have some talented programmers to thank for it.

## Tangling with Inertia

I didn’t know it could happen, but it appears it has: I am at a point in my code where I cannot independently think of any way to fix what is wrong with the creator. No matter how often I look through the code, no matter how much tweaking and debugging I do, I am absolutely stuck. I am waiting to hear back from people with much greater experience in Python than I, but in the meantime, I cannot go forward.

Strictly from a personal standpoint, this doesn’t bother me. I understand that this is just one more hurdle to overcome in the grand scheme of learning to program. But from a development angle, it means I’m not working while I wait for feedback, and since I’m not working, it comes as no surprise that no progress is being made.

I have pondered the idea of working on secondary projects as many developers do, but I’m not sure if this is a wise idea in my situation. Many of the developers I know design and code for several hours a week, whereas I do this in my spare time after a full day of work. That’s not to prop either practice, but it does mean that if I split the two hours a day I have to code amongst many different projects, the little time I do have will be spread rather thin. Perhaps that’s a good thing, as it will keep me from getting bored or frustrated with a single undertaking. On the other hand, though, it waters down my focus in a time when I have too little focus to give in the first place.

What would you all do? Would you work on more than one project at once or would you bang your efforts against a particular obstacle until you manage to break through? All opinions welcome!