programming

There are 19 posts filed in programming (this is page 1 of 3).

A Wild "import *" Appears

We all know that doing from foo import * in python is not good.  Here's a specific instance I recently ran into which demonstrates how this can cause problems.

I was cleaning up some code, and decided to organize a decently sized list of imports (as outlined in the PEP8 style guide).  To my surprise, simply changing the order of the imports broke the code.  Scanning through the list, I spotted a from foo import * statement, which turned out to be causing problems.

Here's the setup:

File foo.py:

1
2

import datetime
# do some stuff

File bar.py:

1
2
3
4

from datetime import datetime
from foo import *
# do some stuff
something = datetime.now() # code breaks here

When bar.py runs, an exception is thrown on line #4.  What's happening is that the from foo import * statement is importing its datetime module, which is overriding the datetime class imported a line above.  This means when you use datetime, you're actually using the module and not the class, as expected.

Science or Fiction Prediction: Getting a Statistical Edge

People sometimes say that if you're not sure what the answer is on a multiple choice question, you should guess c.  I've always wondered if such a system could be applied to the Science or Fiction section on The Skeptic's guide to the Universe (SGU) podcast.

What a multiple choice test may look like

What a multiple choice test may look like

Quick background for non-listeners:  The Skeptics Guide to the Universe is a super great science podcast that you should listen to.  Each episode, they play a game called Science or Fiction, where one host (usually Steve) reads science news items or facts, one of which is completely made up.  The others then try their best to determine which one is the fiction.

While it isn't practical to examine all of the multiple choice tests that have ever existed to determine if c is more likely to be correct, we can actually take a look at each round of Science or Fiction.  It turns out that they keep good show notes on the SGU's website, including each science or fiction item and whether or not it's true.

As of this post, there are 480 episodes, so it's not practical to get the data by hand, but since each episode's page is neatly organized on the website it only took a couple minutes to whip up a little scraping script with python and Beautiful Soup to get the data. (Interestingly enough, scraping through all of the pages I found a tiny mistake: Item #1 of episode 247 is missing a "1".  This broke my scraper the first time through.)

I only collected information about episodes where there were three science or fiction items (which is most of them), so that we can make a meaningful comparison:

Item 1 Item 2 Item 3
Frequency 128 119 133
Probability of Fiction 33.7% 31.3% 35.0%

So it appears that item 2 is fiction less often than items 1 and 3.  The question is, is it a "real" difference, or is it just part of the expected statistical background noise?  Basically, we're trying to empirically determine if Steve uses some sort of random number generator to determine which item will be the fiction each week. Doing a chi squared test tells us that there's a 67% chance of observing such a difference.

In other words: the frequencies are consistent with a uniform distribution, and you can't get a significant edge based on the item ordering.  Steve outsmarts us again!

I did the data collection and analysis with ipython, and you can check out the code here.

More Fun with OCN Server Data

This is a follow up to the previous post about tracking Overcast Network's (OCN) server activity.

A couple things:

  1. At the time of that posting, there were only a few days of data in the database.  Since then, the script has been churning away for the past few weeks, giving us a much larger sample.
  2. The original scripts spend most of the time juggling dictionaries and reshaping the data to plot.  This isn't particularly elegant.  This time around I'm using Pandas for the data preprocessing after restructuring the database.

In retrospect, it would have probably made more sense to store the information in an SQL database. I used MongoDB only because I had never used it before (my favorite reason), and the prospect of being able to dump python dictionaries right in seemed fun.  And I pretty much did just that - dumping dictionaries of data - which seemed simple enough at the time but ultimately led to processing complications later (see above).

eu-counts

With all of this in mind, I played with the data a bit in an ipython notebook, and so it only makes sense to display the code and results using the very cool browser notebook viewer.  Check them out here!  (If you aren't using the ipython notebook daily, you're blowing it. It's a lot of fun.)

As you can see from the plots, the player count varies quite a bit throughout the day, even with a very large spread of players across the globe.  This can cause some issues since many of the servers are designed with a certain number of players in mind.  OCN recently implemented dynamic servers, which turn on and off depending on the number and distribution of players online and will hopefully solve this issue.

Code and more graphs

Tracking Overcast Network's Player Count with Python

eu_main

 

Python quickie!  Overcast Network is a large minecraft network and they have a lot of servers.  They don’t keep track of the player count on all of these servers over time, so to assess the popularity of the different servers I wrote some scripts to collect server data and plot the results.

The collection script runs every 15 minutes via cron, grabs data from the play page and dumps it in a mongoDB database.  The plotting class gets the data from the database and does a bunch of data maneuvering so it’s easy to work with (I should probably learn how to use data frames at some point) and then plots it with matplotlib:

 

eu_main

eu_main

These plots show the average player activity per day (in one hour bins).  There are only a few days worth of data shown here, which explains why the points tend to jump around a lot.  As more data is collected, things should smooth out a bit.  You can see more plots here.

Source

Related server tracking:

http://mc.ttaylorr.com/

Quarrying with ComputerCraft Turtles

I just recently began playing with ComputerCraft, which is a very cool Minecraft mod that adds programmable computers.   There are also turtles, which are basically computers that can carry out tasks like mining, digging, attacking, etc.  Turtles are fully programmable using Lua and various APIs.  You can do lots of amazing things with turtles.

This is not something amazing, but just a simple modification I made to the turtle's excavate program that allows you to dig stepped quarries giving easier retrieval of the ores around the edges:

9x9 excavate:

excavate14x14x3 quarry:quarry

 Source. You can copy this script directly to your turtle using the turtle's pastebin program.

To dig a quarry, you specify the diameter and the number of blocks to dig down at each diameter, .

It's a fun exercise to work out some of the properties of the resulting quarries.  Given a and , you can dig a quarry that is blocks deep, where if is even and if is odd.  The total height of the quarry is related to the number of constant-diameter levels, by .

Given a and , the total number of blocks you mine in a quarry, , is found by simply adding up all the blocks at a given level and then adding all the levels.  Noting that decreases by two blocks each time you make the quarry square smaller,

where is related to .   Writing this in summation form,

where .  Now, the summation bit is straightforward to see, but the upper limit took some playing around in Mathematica for me to work it out.  This seems to work pretty well, but if anyone can derive this limit (or a better one) more "rigorously", please let me know!

Anti Rage-Induced-Accidental-Disconnect Minecraft Client Mod

We've all been there: You're playing on your favorite Minecraft PvP server, ready to get revenge on the player who just killed you, when suddenly, you're staring blankly at Minecraft's title screen.  How could such a thing happen?  Well, maybe Mr. McMillan has something to say about the matter:

 

Yes, Mr. McMillan, precisely.  The death screen GUI has "Respawn" and "Title screen" buttons that are way too close to each other, resulting in players sometimes unintentionally leaving the game when they actually want to respawn.  Now, this isn't something that happens all the time, but it happens occasionally and it's annoying.

So, in the first and only installment of the new (and old, by the time you read this) series "Weekly 1 Minute Minecraft Mods", we can fix the problem.

We will change this:

 

Before

into this:

 

After

(Texture pack is the beautiful Plast Pack.)

The new layout isn't pretty, but in the case of PvP I'll definitely take function over fashion (with the exception of gold pants).

Making the Mod

You need to download and install Minecraft Coder Pack (MCP).  There is a lot of information about how to do this online.

Once MCP is ready to go, find the file "GuiGameOver.java" in the minecraft/src subdirectory.  In this file, there are only two lines we need to modify:

1
2

this.buttonList.add(new GuiButton(1, this.width / 2 - 100, this.height / 4 + 72, I18n.getString("deathScreen.respawn")));
this.buttonList.add(new GuiButton(2, this.width / 2 - 100, this.height / 4 + 96, I18n.getString("deathScreen.titleScreen")));

These files add the "Respawn" and "Title screen" buttons.  The only thing we need to change is the third argument to the GuiButton constructor.  We can shift the buttons up and down by changing the values of 72 and 96, with larger values corresponding to a lower position on the screen.  The "after" photo shown above uses values of 70 and 120:

1
2

this.buttonList.add(new GuiButton(1, this.width / 2 - 100, this.height / 4 + 70, I18n.getString("deathScreen.respawn")));
this.buttonList.add(new GuiButton(2, this.width / 2 - 100, this.height / 4 + 120, I18n.getString("deathScreen.titleScreen")));

Once this is changed, save it and then proceed as you would with any other mod (recompile, reobfuscate, and drop the class in the appropriate Minecraft .jar file after backing everything up, etc.). Now you can crank up your mouse's sensitivity and fail to unintentionally disconnect from your favorite server with ease!

Note that this does involve changing core Minecraft files and so may result in issues if there is an overlap with another mod.  Also, it seems this won't be an issue when 1.7 comes out.