Forensic Bioinformatics and Clinical Trials

From a Nature News article titled Cancer trial errors revealed:

Now, in response to information obtained by Nature under the US Freedom of Information Act, Kornbluth and Cuffe have offered their account of the mistakes that led the trials to be restarted even after they learned of potential flaws in the underlying data. The affair will have an impact beyond Duke, as the Institute of Medicine, part of the US National Academies in Washington DC, begins to examine research on genome-based patient testing. Originally commissioned to investigate Duke's controversial trials, the institute's US$687,000 study is now expected to focus on providing broader recommendations for the design of clinical trials that similarly use genomic data from individual patients to tailor therapy.

This seems like a big mistake on the part of the panel.

Related:

Make Up Your Own Rules of Probability

Irreproducible Analysis

Resolving Debates in Statistics

Occasionally there are debates in science about what models are formally appropriate for thinking reasoning about scientific concepts. These include:

- The existence of race as a meaningful concept in light of current knowledge about human genetic diversity. See Richard Lewontin's article "The apportionment of human diversity" (1972) and Lewontin's Fallacy for more information.

- Quantum and classical physics.

- Bayesian and Frequentist methods for statistical inference.

Scientists have chosen sides in these debates based on education, philosophical preference, and sometimes practical concerns. Usually these debates can be reduced down to the appropriateness of certain calculations in solving scientific problems. For example the Bayesian-Frequentist debate largely centers on the incorporation of prior information into inferential calculations. In "Confidence Intervals vs Bayesian Intervals," by ET Jaynes suggests that all of these debates over methods can be resolved by benchmarking methods on a set of focused problems:

I suggest we apply the same criterion in statistics: the merits of any statistical method are determined by the results it gives when applied to specific problems. 

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.