Building a Neural Network in Elixir
Contributed by Tom Welsh. Tom is currently in the NYC Data Science Academy 12 week full time Data Science Bootcamp program taking place between January 11th to April 1st, 2016. This post is based on his scraping project by using new language -- Elixir (due on the 8th week of the program).
My scraping project thoroughly convinced me that I didn't enjoy working with python. I'd been reading a lot about Elixir, a relatively new functional language built on top of Erlang/OTP, and decided to give it a try.
Elixir's underlying parallelism makes it a natural fit for working with big data. However, as a relatively new language, there's a relative lack of machine learning libraries. Elixir can call into Erlang libraries, and people have been working in this space, but I couldn't find libraries that were publicly available. There were a couple of Elixir Neural Network implementations on github, but nothing that seemed to be in active use.
As such, I realized I'd have to start from scratch. I decided to build a neural network, in part because they're naturally suited to leverage Elixir's parallelism, but mostly because they're pretty cool.
A few of my design choices:
- Process layers sequentially, with no skipping of layers. This limits the complexity of the implementation at the expense of reduced flexibility and reduced parallelism.
- Process the neurons within a layer in parallel. This at least gives me some parallelism.
- Support arbitrary numbers of layers and neurons.
- Intelligent and simple handling of factors. I specifically didn't want to require that the set of possible factor values be known in advance.
- A very simple interface for creating and training the network.
Each neuron was represented by an OTP Agent. For both forward and backward propagation, OTP Tasks were spawned to update each node, and then the results were collected and passed to the next layer.
Here's an example of creating a network with two hidden layers of 5 neurons each:
{:ok, net} = GenServer.start_link(Elyanah.NeuralNet, [5,5,1])
Making a prediction:
[prediction] = GenServer.call(net, {:predict, input})
Backpropagation:
GenServer.call(net, {:backprop, output, learning_rate})
To test the network, I created four test cases:
- The most basic was a simple repeating pattern of
[0,1]and[1,0]. As expected, the network quickly learned to differentiate between the two cases. - A slightly more realistic test case involved creating two random base cases of 10 values between 0 and 1. Each input to the network was one of the base cases another 10 random values between 0 and 1 added to it. The network was able to learn which of the base distributions was used to generate a given input.
- To test the handling of factors, a corpus of words (mostly Beatles lyrics) was split into an array of characters, and each array of characters being fed in as an input. As such, each character would be treated as a factor. The desired output was whether the word count was even or odd. While the network was able to correctly handle the factors, it did not succeed in learning on this problem, producing outputs no better than a random guess.
- Finally, NBA shot data for the current season was pulled in from ESPN's APIs. This included the shooter and location of each shot. This was fed into the network with the goal of predicting whether the shot would be made or missed. Since the underlying data was highly random, I didn't expect to be able to get significantly better than random, and my initial attempts were largely unsuccessful. However, after changing the coordinate system of the shot locations, I was able to beat random, so I'm considering it a success.
To test the scalability, I created networks with varying numbers of hidden nodes. The performance was pretty good until the number of nodes got into the low hundreds, then fell off badly. Regrettably, the network did not seem to be using all of the available hardware threads on my laptop. I've read that the current version of the Erlang interpreter is less aggressive in scheduling processes to run on multiple cores, and I suspect that the amount of work done in each Task was insufficient to justify the costs (in moving data around) of scheduling it to run on another core. However, I have not had the opportunity to look into this in more detail.
A more sophisticated approach would be to create a separate OTP GenServer for each neuron, with awareness of their incoming
and outgoing connections, and data being cast through the network from neuron to neuron without the bottleneck of collecting the results from each layer. I hope to try this approach in the future.
About Author
Tom Walsh
View all posts by Tom Walsh >Related Articles
Leave a Comment
