After moving to NYC for the summer, I found myself in need of a new bike. The bike I rode across the country last summer was always a little too small for me, and after growing about half an inch in the last year, it really doesn't fit me anymore. I was going to bring a bike to NYC for commuting, but it got stolen out of my car when I was visiting San Francisco. Luckily the one that got stolen was kind of a piece of junk. It was a fixed gear strapped to a cheap origin8 frame. The one thing I liked (and now miss) were the larger volume tires and the wide mountain bike handlebars. There's something about rolling around on a fixed gear with wide-ass bars that just puts a smile on my face.
Wednesday, July 27, 2016
Tuesday, July 26, 2016
Monday, March 14, 2016
Simple MLP with Torch 7
I've been busy working on my capstone project lately. The goal of my project is to be able to distinguish between good and bad data generated by the XENON100 dark matter experiment. Researchers at the collaboration have been using some simple cut based methods to get rid of noisy data, but as the experiment has aged these methods have become really inefficient. In other words, they've been throwing away a lot of data that could include the signal from a dark matter interaction event. Long story short, I'm using some machine learning techniques to categorize data into "good" and "bad" categories. A method called boosted decision tree (BDT) has proven to be pretty effective at this task in the past, and I'm using an implementation bundled in this piece of software called TMVA. TMVA has been used for data analysis in a variety of high energy physics experiments. It's pretty effing cool because it includes many classification algorithms, including, but not limited to SVM (support vector machine), MLP (multilayer perceptron), BDT, other decision tree methods, and a bunch of stuff I've never heard of. Skip the next bit if you don't want to read my rant on ROOT. It's awful because it's all built in ROOT. I don't want to learn ROOT. I'm a Python programmer, with some experience with Java and JavaScript. I see all those asterisks, arrows, and character arrays and my eyes glaze over. I've tried to write some basic ROOT "macros" but they throw these cryptic errors that don't make a damn bit of sense. You don't realize how spoiled you are with Python until you use something like ROOT. The worst shit is the interface between Python and ROOT. There is a pretty decent library called rootpy, but the documentation and source code is all but impenetrable (500 line pieces of code just to bind the ROOT histogram class to Python ???). When rootpy works, it is pretty Pythonic, but it doesn't allow for a ton of flexibility. Say you run some stuff through TMVA, and you want to grab and manipulate some histograms that are stored in root files. Forget about it. You just can't.
I should note that ROOT has some very powerful tools for data analysis, and it's pretty darn fast, as it's built right on top of C++. If part of my capstone were learning ROOT, I think I'd be a little less critical, but right now I see it as this obnoxious obstacle to me doing my analysis.
Anyways, I thought it would be cool to see if I could dump some of the data I've been creating into another machine learning framework and see if I can categorize my signals. In the past, I've used Theano, and found it to be really difficult. Even the tutorial on the most basic neural net architecture (MLP) stymied me. Even though I implemented my own version of a MLP, I still felt very uncomfortable with Theano. Lately, I've moved to Torch. Torch is awesome. Below is the code for setting up and training my MLP.
Okay, okay, I'll admit the line for setting up the training seems pretty black box. Implementing something similar to the built in stochastic gradient descent is not that tricky though. (I'll show some code that does it soon). Basically you chop up your training dataset into chunks (minibatches), feed it through the net, calculate gradients, and update weight matrices. Torch is built on Lua. Lua is pretty straight forward. Lua isn't as widely divulged as Python, so there isn't as much help on line, but it's not terrible. Torch's documentation is on github, and like matplotlib, is contained in one big page. This is a bit obnoxious, but not the end of the world. The biggest issue with Torch at the end of the day is loading and creating datasets. The code that loads in my data (stored in csv files) is about twice as long as the code to build the MLP. Once you have it though, the neural net is almost trivial (at least compared to Theano). As I delve deeper into this stuff, I'm sure I'll find that Torch is every bit as complicated as Theano, but I'm pretty happy for the moment.
I should note that ROOT has some very powerful tools for data analysis, and it's pretty darn fast, as it's built right on top of C++. If part of my capstone were learning ROOT, I think I'd be a little less critical, but right now I see it as this obnoxious obstacle to me doing my analysis.
Anyways, I thought it would be cool to see if I could dump some of the data I've been creating into another machine learning framework and see if I can categorize my signals. In the past, I've used Theano, and found it to be really difficult. Even the tutorial on the most basic neural net architecture (MLP) stymied me. Even though I implemented my own version of a MLP, I still felt very uncomfortable with Theano. Lately, I've moved to Torch. Torch is awesome. Below is the code for setting up and training my MLP.
Okay, okay, I'll admit the line for setting up the training seems pretty black box. Implementing something similar to the built in stochastic gradient descent is not that tricky though. (I'll show some code that does it soon). Basically you chop up your training dataset into chunks (minibatches), feed it through the net, calculate gradients, and update weight matrices. Torch is built on Lua. Lua is pretty straight forward. Lua isn't as widely divulged as Python, so there isn't as much help on line, but it's not terrible. Torch's documentation is on github, and like matplotlib, is contained in one big page. This is a bit obnoxious, but not the end of the world. The biggest issue with Torch at the end of the day is loading and creating datasets. The code that loads in my data (stored in csv files) is about twice as long as the code to build the MLP. Once you have it though, the neural net is almost trivial (at least compared to Theano). As I delve deeper into this stuff, I'm sure I'll find that Torch is every bit as complicated as Theano, but I'm pretty happy for the moment.
Tuesday, February 23, 2016
Annoytron 3000 update
Ben and I have been hard at work getting the annoytron up and running. We've solved a number of problems with our circuit such that the only challenge we now face is one of miniaturization. With the help of one our idea lab colleagues, Ben found something called a thyristor that allows us to turn our circuit on, but not turn it off. This means that users will not be able to turn the device off using the main power switch. This solves perhaps the biggest problem associated with our project. Now we don't have to worry about hiding the power switch or introducing some sort of software solution -- we have a single component that allows us to control the way users interact with the on switch. We've got a very basic working prototype contained in a cardboard tube. Check out some pictures below.
In addition to the switch problem, we were having trouble figuring out how we would charge the battery. Looking around online, I found some nice looking breakout boards that allow one to charge the battery while plugged in, but they looked too large for our purposes. We ultimately settled on a simple circuit that will charge the battery as long as the battery isn't being used by the Arduino. We think this is a reasonable decision, as Ben and I assume that users won't be using the dildo while it's plugged in.
The power regulator we're using has a "shutdown" pin, which cuts power when pulled to ground. This allows us to automatically turn of the device after the user brings it to completion. I hooked up a transistor to the shutdown pin I think my colleagues in the Idea Lab will appreciate this, as the piezo is really obnoxious.
Moving forward, Ben and I need to print another, larger dildo (so we can fit all the electronics inside) that doesn't have any internal structure. I'm anxious to get this device put together so we can start annoying Allen.
![]() |
| Annoytron with guts shoved inside. |
![]() |
| Annoytron with guts hanging out |
![]() |
| On/off switch. We'll be changing this out later. Using this switch feels great. |
In addition to the switch problem, we were having trouble figuring out how we would charge the battery. Looking around online, I found some nice looking breakout boards that allow one to charge the battery while plugged in, but they looked too large for our purposes. We ultimately settled on a simple circuit that will charge the battery as long as the battery isn't being used by the Arduino. We think this is a reasonable decision, as Ben and I assume that users won't be using the dildo while it's plugged in.
The power regulator we're using has a "shutdown" pin, which cuts power when pulled to ground. This allows us to automatically turn of the device after the user brings it to completion. I hooked up a transistor to the shutdown pin I think my colleagues in the Idea Lab will appreciate this, as the piezo is really obnoxious.
Moving forward, Ben and I need to print another, larger dildo (so we can fit all the electronics inside) that doesn't have any internal structure. I'm anxious to get this device put together so we can start annoying Allen.
Tuesday, January 26, 2016
Annoy-tron 3000
I'm currently working on a little project with my buddy Ben. The goal of the project is to make something that will annoy Allen. The electronics we build for this project can definitely be used for other, more potentially profitable purposes I believe. The idea of the project is to embed a temperature sensor, Arduino and buzzer in an 3D printed dildo. By themselves, Arduinos can only generate square waves which are super obnoxious when very high pitched. I envision a typical interaction going as follows. A user will be presented with a screeching dildo. He or she will be told that he or she can only turn it off if they can heat up the dildo past a certain threshold. After furiously heating up the dildo, it will eventually turn off. The interaction here is quite simple, but this project entails an interesting technical challenge. We have to embed an arduino, on/off switch, buzzer, temperature sensor, battery and charging implement in a prosthetic phallus. The on/off switch has to be sufficiently difficult to reach that the user is incentivized to rub the dildo instead of trying to turn it off. We also need to able to charge the battery while still plugged into the Arduino.
In future posts I'll put up some pictures so Ben and I can track our progress.
In future posts I'll put up some pictures so Ben and I can track our progress.
Jterm 2016 - UAE and Oman
Over J-term, I had the opportunity to leave coding, electronics and Physics aside for a few weeks. I took a class in which we travelled all over the UAE and part of Oman. I was able to make some new friends and spend some quality time with my boy Eder. The class itself was interesting as well. In principle, the purpose of the class was to study the interaction between three different landscapes in the region (Oasis, Coast and Mountain, also the name of the course). In my mind the overriding themes of the class were water management, increased dependence on modern economies, and the interaction between place, state, and identity.
Monday, January 25, 2016
Final Project for Interactive Media
While I've been concentrating a lot on plotting cool systems of differential equations, I want to move my attention a little to the realm of making physically interactive systems. My final project for interactive media is a good example of the kind of stuff that I want to investigate in the coming weeks. My inspiration for the project was the thought that I might be able to feel a virtual electric field. By virtual, I mean that I wouldn't be actually creating an electric field and using a physical sensor to detect it. Instead, I place a virtual point charge at some point in space, and by moving her hand about in the neighboring space, a user can feel how the magnitude of the field changes.
Subscribe to:
Posts (Atom)


