Skip to main content

Posts

I’ve greatly enjoyed my time as a graduate research intern at DeepScale and so I was pleased when Forrest Iandola asked me to give a talk to his team on deep learning hardware. To keep the talk from being a boring list of slides recounting famous (but dry) neural network hardware papers, we decided to structure it like one of David Patterson’s talks which describe what not to do. The talk was well received, so I decided to reformat it into this blog post.

If you’ve read my post about patenting in academia and industry then you know why you might want to file a patent with your university or company. The first step to filing a patent in most organizations (after creating the invention of course!) is filling out an Invention Disclosure Form or IDF. These forms will be created, provided by, and reviewed by your organization’s technology transfer office or center for technology licensing.

We all get excited about doing scientific or engineering research for different reasons, but most of us seek the thrill of creating something entirely new. In this way, research can be just as wonderful as the creative arts. Publishing your new ideas is great for sharing information with the world, but sometimes you want to sell your ideas too. This is where filing for a patent can be very useful. I have some experience in this area as I have patented inventions on my own, in industry, and most recently in academia.

While building the downloading and decoding scripts for the Youtube BoundingBoxes dataset I needed to accurately cut videos into smaller clips. Some of the annotated videos were quite long and the annotations rarely covered the full video, so to save space my scripts cut out and save only the annotated sections. If done incorrectly this video cutting can cause subtle frame timing issues which I didn’t fully understand when I started writing these scripts.

Back in 2010 I started a blog dedicated to electronic music called Quoth the Raver (a play on Quoth the Raven). It was a huge amount of fun sharing the music I found with everyone on the site, and it inspired me to get even more familiar with the various genres, artists, and labels. These days electronic music (also known as EDM) has exploded in popularity, so the novelty of sharing new artists has worn off to a certain extent.

As an academic I am often writing LaTeX code for publications or general documentation. I used to use ShareLatex and Overleaf because I have a secret love of GUIs (Lord forgive me!), but recently my co-authors have prefered to work in LaTeX repos shared on GitHub. For this reason my most recent paper was actually written entirely in Vim! This post isn’t meant to be a complete description of the best way to edit LaTeX in Vim, but instead I want to share some of the tools, tricks, and tips that I’ve found useful when writing LaTeX in Vim.

Most of us academic/industrial ECE/CS researchers want to make our results as reproducible as possible. Its good for the integrity of our field and it also helps future researchers and developers to build on our prior work. GitHub is great for distributing software, but code can rarely be compiled and run on its own as nearly all modern software relies heavily on packages and dependencies. Installing these dependencies can be incredibly frustrating or possibly even impossible depending on how long ago the code was written.

Anyone who’s set up a new Linux based, GPU enabled, deep learning system knows the horror that is driver installation. While it is technically possible to install NVIDIA drivers and CUDA from your package manager, the most up to date versions aren’t available and in the worst case you might even break graphics on your machine. After a great deal of difficulties installing and reinstalling, I finally found a viable strategy: installing both CUDA and proprietary Linux drivers from an NVIDA run file without OpenGL libraries.