Code

Code

Friday, August 28, 2015

Bot Battle

For those of you who don't program, it may be hard to understand just how slow a process it usually is. Movies and other media don't help this misunderstanding. As Mark Zuckerberg put it, "If they were really making a movie, it would have been of me, sitting at a computer coding for two hours straight". Similarly, here's a visual representation of the difference.

Every once is a while though, it's actually useful to be able to throw together a quick script, or to generate a plot while you're having a discussion with your colleague. It's not something I'm particularly skilled at since I don't do it much. So is there some fun way to practice coding quickly?

Let's make a bot battle competition!

I wanted this to be a pretty straightforward weekend project, so I decided to stick with a simple game that I love a lot. Reversi, also known as Othello is a great game that even little kids can easily understand. The game itself hasn't been solved though, so it's far from trivial. It's the perfect game for this sort of project.

I'm not going to run through all of the code or anything, but the repo is available if you want to try it out yourself. A more detailed explanation of how to run the code is there, as well as the general rules of the game. If you don't feel like playing yourself, here's a quick clip of what a Series might look like:




If you have any suggestions or need help setting up the game, just let me know!

Cheers!

Friday, August 7, 2015

The Perceptron

Today in lab meeting, during our bi-weekly "Idea Potluck", I dropped the ball while explaining how perceptrons work. We were running short on time, so I rushed and straight-up got flustered. It was unfortunate, since perceptrons are really cool, and Wikipedia has a great example (here).

To over compensate, I've written a tutorial to go along with the Wikipedia example.

http://nbviewer.ipython.org/gist/Jessime/62c2a8a0baa2c0d061b8

The example and the code are really straightforward, so check it out!

Cheers!

Monday, August 3, 2015

Bioinformatics Software

This isn't a long post, but I read something interesting the other day and wanted to repost it. First, here's the link to the blog: 

http://www.bioinformaticszen.com/

But since the post is so short, here it is in it's entirety:

"Every piece of software written for publication, which then can't be found after publication is grant funding thrown away. Every piece of software that only worked for the author during manuscript preparation is grant money thrown away. Every piece of software reinvented solely for the purpose of adding a new feature and publishing is grant money thrown away.
Grants are harder and harder to obtain, yet we fund the current attrition of moving bioinformatics software forward one reinvention at a time. Where else is it acceptable to reinvent a tool rather than try to improve upon an existing one? Count how many types of webservers are commonly used across the web, then count how many different genome assemblers have been published. If we were a company and we behaved this way, we would have gone out of business long ago. We have accepted a state whereby the short-term reward of publication trumps the longer-term goal of maintaining and improving existing open-source software. We now reap the rewards of this every time we can't find stable software to run our analyses."

I think anyone who's tried to learn bioinformatics instinctively knows this is true. Instead of whining about just how true I've found it to be in the past year, I'll offer two high-level solutions. By "high-level", I realize I ignore all of the depressing, nitty-gritty details.

1. Reproducing computational results must be encouraged and rewarded. Given the current research environment, the rate of independent software validation is unlikely to increase. We as a community must find methods to foster reproducibility; perhaps in ways as simple as offering "bounties" to teams or individuals who validate newly published software.

2. Guidelines for software publication should become as strict manuscript guidelines. Here's an outline of what's needed to publish to Science:
http://www.sciencemag.org/site/feature/contribinfo/prep/prep_init.xhtml
Where's the equivalent document for software? "Software" isn't even mentioned at all in the guidelines.