Sometimes Big Changes Are Better

In college, I was never formally taught the art of debugging. Often in my first few programming classes, I'd end up rewriting chunks of code that weren't giving proper results, as big changes can occasionally be easier than small changes. I'm also a fast typist, so the cost of typing a few hundred lines is relatively low for me.

I always felt strange about this, because it seemed like making big changes to the code in this way is a poor practice. Interestingly, that Peter Norvig occasionally does the same thing, and doesn't even need to understand the details of the bug in order to fix it.  Here's an excerpt from Peter Seibel's excellent book Coders at Work:

Seibel: On a different topic, what are your preferred debugging techniques and tools? Print statements? Formal proofs? Symbolic debuggers?

Norvig: I think it's a mix and it depends on where I am. Sometimes I'm using an IDE that has good tracing capability and sometimes I'm just using Emacs and don't have all that. Certainly tracing and printing. And thinking. Writing smaller test cases and watching them go, and breaking the functionality down to see where the test case failed. And I've got to admit, I often end up rewriting. Sometimes I do that without ever finding the bug. I get to the point where I can just fell that it's in this part here. I'm just not very comfortable about that part. It's a mess. It really shouldn't be that way. Rather than tweak it a little bit at a time, I'll just throw away a couple hundred lines of code, rewrite it from scratch, and often the bug is gone.

Sometimes I feel guilty about that. Is that a failure on my part? I didn't understand what the bug was. I didn't find the bug. I just dropped a bomb on the house and blew up all the bugs and built a new house. In some sense, the bug eluded me. But if it becomes the right solution, maybe it's OK. You've done it faster than you would have by finding it.

This is a really smart way to think about debugging. We don't have infinite time to understand the minute details of some mistake made in the past. What's important is to get things working as quickly as possible. As long as the code has the desired functionality and passes tests appropriately, sometimes rewriting big chunks of code can be an effective debugging method.

Using a Closure to Make Panel Labels in R

When making plots with several panels, I very often want to label the individual panels with letters of numbers. I like to have a simple function for labeling panels, like this:

# create a plot

plot( x, y )

# assign a unique label to the plot
panel_labeler()

Below the break is a definition for the panel_labeler() function using a closure in R. Shown are some examples of using panel_labeler() assign labels to plots. The plots show different methods for combining mixtures of Normal distributions, but this approach could be used for plotting anything.

Infrequently Asked Questions about Perl

I just read a few entries from Infrequently Asked Questions about Perl, a hilarious list of joke answers to serious questions by Mark Jason Dominus. Here are some of my favorite entries:

How do I get tomorrow's date?

Use this function:

sub tomorrow_date {
          sleep 86_400; 
          return localtime();
        }

How can I find out whether a number is odd?
sub odd {
            my $number = shift;
            return !even ($number);
        }
How can I find out whether a number is even?
sub even {
            my $number = abs shift;
            return 1 if $number == 0;
            return odd ($number - 1);
        }

Action Shots of Water Ballons

Just saw a great article on NPR's web site about Edward Horsford's photographs of water balloons as they burst. The photos are brilliant, they capture the rupturing plastic and swirling water as the balloon breaks. 

• Edward Horsford's Flickr Stream
• NPR Article: Water Balloons Without The Water

On his Flickr stream are several other fun shots, including a detailed close-up of a spider and another of a snowflake.  

Illegal Manipulation of Automated Trading Systems

From this CNBC Article:

Two Norwegian day traders have been handed suspended prison sentences for market manipulation after outwitting the automated trading system of a big US broker.

The two men worked out how the computerized system would react to certain trading patterns – allowing them to influence the price of low-volume stocks.

This could become a more serious problem as trading systems become more automated, and I suspect that there are cases similar to this one that we never hear about.

One argument made by the defense is interesting: the defense lawyer admits that his clients misled the trading algorithm in order to make a profit, but weren't responsible for the actions of the computer. They're appealing the case.

String Lengths in R

For some reason, in R this does not do what I expect:

string = "mystring"
print( length(string) )
[1] 1

What I actually want is this function:

print( nchar(string) )
[1] 8

An Idea Whose Time Has Come

If you enjoy literature, politics and satire, you'll love ShakesPalin.

After inventing the word "refudiate" and subsequently comparing herself to Shakespeare as a wordsmith, Twitter is abuzz with posts bizarrely fusing quotes from the Bard on Avon and the Thrilla From Wasilla. Here are some of the better ones:

Alas, poor Couric, I read them all.

But soft, what light from yonder window breaks? It is the East, and I can see Russia from my front porch.

Here's my personal favorite:

Be not afraid of mavericks: some are born mavericks, some achieve maverickry, and some have maverickness thrust upon 'em.