Jump or Not to Jump: Solving Flappy Bird with Deep Reinforcement Learning w/ Kaleo Ha’o

kaleo-haoThe holy grail of machine learning has always been a “Skynet” type of artificial intelligence that could generally learn anything (artificial general intelligence), and the biggest advancement toward achieving such A.I. is deep reinforcement learning (DRL). The reason for this is DRL’s ability to solve a vast array of problems; its application ranges from learning any video game, to driving autonomous cars, to landing Space-X Falcon 9 rockets. As such, DRL is one of the most exciting fields in machine learning, and will continue to be so for the foreseeable future.

This talk will be a deep dive into the math behind an algorithm which uses DRL to solve the video game Flappy Bird. Additionally the goal of this talk will be such that even the most math-phobic beginner-to-ML will walk away excited about DRL and able to verbalize the central equation to DRL. This will be done in two simple steps. First we will derive the Bellman Equation (classic reinforcement learning), which provides a framework for the algorithm’s decision making process. Second we will use that Bellman Equation to derive a custom loss function, which will drive the training of the algorithm’s deep neural network (deep learning).

To keep things simple during presenting, Kaleo will skip the code snippets but links will be provided where everybody can download the Flappy Bird algorithm’s code, a 20 page paper (written by Kaleo) detailing the algorithm, and a list of resources for further study.

The following is a link to the algorithm code and accompanying paper (PDF), where the math details can be found in section Algorithms and Techniques: https://github.com/06kahao/Improved-Q-Learning-Multi-Environment

Kaleo Ha’o (@06kahao) is a graduate from Udacity’s Machine Learning Engineering program, Kaleo Ha’o is a freelance ML engineer who loves to contribute to Open A.I. research on reinforcement learning.

Eliminating Machine Bias w/ Mary Ann Brennan & Getting from Machine Learning Outputs to Decisions… timely things!

Meet Mary Ann Brennan (@mabmierau) presenting…

Eliminating Machine Bias

mary-ann-brennan

Mary Ann is a jack-of-all-trades software engineer with background in iOS and full-stack web at a bunch of startups you’ve probably never heard of. She’s currently using her extended maternity leave to refresh her studies in Artificial Intelligence, the concentration for her master’s in Computer Science at Stanford. She recently completed Coursera’s Deep Learning specialization.

Mary Ann will give a quick overview of the machine bias problem. She’ll provide a definition (and contrast with statistical bias) and show examples like criminal justice system algorithms with racial bias and machine translation algorithms with gender bias.

Mary Ann will also pull an example from the Deeplearning.ai courses that shows how to remove gender bias from word representations. She’s been surprised how simple and manageable it was to do and hopes this will help inspire people to take the extra step to consider how they might eliminate bias in their work. Time permitting, she’ll also aim to round the talk out with other techniques and more info on what to look for in your own data.

In Brennan’s talk, there may even be a code up of web-based interactive before and after view of word representations that you can check out, maybe. Be sure to ask about it, as it might be in under construction!

Meet Robert Dodier (@robert-dodier) presenting…

Getting from Machine Learning Outputs to Decisions

robert-dodier

Robert is interested in Bayesian inference and decision analysis, among many other topic. He’s got a background in math, computer science, and engineering. He also wrote his PhD dissertation on Bayesian network models applied to engineering problems. Since then he’s worked on statistical analysis, including machine learning, in different domains and also worked for some years on a agent-based system for control of distributed energy resources.

You’ve set up a machine learning pipeline and it’s delivering predictions and estimates in real time just as you hoped it would! Now, what can you do with those numbers? Intuitively, we think that if we compute a prediction that an event A is more likely than another event B, we should probably take an A-related action instead of a B-related action. But not if the A-action is really expensive compared to the B-action; then we’d hesitate unless we’re very sure about A. We could set up some rules to post-process the predictions to figure out which action to take. That sounds kind of hackish.

But wait! The good news is that we can formalize the decision problem in terms of statements of beliefs (i.e., probabilities) and values or preferences (i.e., utilities). Typical machine learning algorithms can produce probabilities, which we’ll take as the inputs for the decision-making step. Given fairly broad assumptions, the right way to make a decision is to take the action which maximizes expected (i.e., weighted average) utility. This gives a straightforward recipe for deriving actions from beliefs and preferences. Typically the expected utility calculation is much simpler than the belief calculation, so we can easily a devise a decison-making back end for our machine learning pipeline.

In this talk, Robert will pose some real-world decision problems and then talk about the features they have in common. He’ll describe a framework for finding best actions for such problems in general, and show how the framework applies to the problems he posed at the beginning of the talk. He’ll emphasize the idea that a formal decision making analysis gives an obvious way to inject business logic into the pipeline in a clear and easily-modified way.

Crazy Conf Notions. Viable?

While at Goto Conf in Chicago today I had two thoughts while talking with Joe (@joelaha) while hanging out with Bridget (@bridgetkromhout) while waiting for Lena’s (@lenadroid) talk on “Distributed Data Stores on Kubernetes“. All that wrapped up into a few ideas for future conferences. Here, I present them to you dear readers, please lament, lamblast, lacerate, or decimate this list of groovy ideas I have. Comments welcome, or scream at me a tweet or two on Twitter @Adron!
Continue reading “Crazy Conf Notions. Viable?”

My Node.js Story

Once upon a time in a part of the tech universe far far away, there was a general consensus to block all JavaScript from browser execution. It was the way things were because JavaScript was seen as harmful. You see, the early miscreants of that time had used JavaScript to write all sorts of problematic code that would attack, steal, or otherwise undermine the data one sent across and received on the internet. This is the time I could have started learning JavaScript, but because of its horrid reputation I stayed far away and wrote C, C++, C#, Java, and event some RPG, COBOL, Pascal, and some other code. It was glorious, and the languages were beautiful in their own ways, while JavaScript was shunned by almost everybody in that tech universe! **

Today, things aren’t all that much different, but we make it easier for the whole horde of miscreant scripters to write problematic code in JavaScript. The difference is we allow it everywhere and just try to catch it and prevent execution. Thus, different, but the same, it’s a crazy world we live in.

I started picking up a little JavaScript at the tail end of 2007, when the “JavaScript: The Definitive Guide” was the top book to delve deeply into using JavaScript. It wasn’t another year until the seminal “JavaScript: The Good Parts” cut down the size of what one really needed to delve into by removing the cruft and focusing on the good parts. Slowly, JavaScript was finally starting to take shape as something useful.

Writing JavaScript at this time was a mutant challenge of having it look like Java while being organized like a trash pile of scripts that had no way to manage dependencies or otherwise. I mean, NPM was years away from existing, and really the concept of libraries in JavaScript seemed to be a foreign concept at the time.

2008 rolled around, “JavaScript: The Good Parts” came out, the changes started rippling through the industry and as traction started to mount. The penultimate event occurred the following year in 2009, which at the time almost nobody noticed. Dahl started Node.js at Joyent to enable server side JavaScript code use. At the time, many were flummoxed by the notion, weren’t confident in the single threaded event loop, and overall its release and the project continuing were in jeopardy from this point.

But the project continued and persisted!

Continue reading “My Node.js Story”

Kubecon Day 2 Keynotes

kubelogo-wide

Kelsey HightowerChen Goldberg, and Anthony Yeh

Day two kicked off (read on for day one wrap up) with Kelsey HightowerChen Goldberg, and Anthony Yeh. The big push from Kelsey and team focused their keynote around the development story around Kubernetes. Specifically, that a developers and apps users, should never need to know they’re using Kubernetes. He, Chen, and Anthony all talked about the idea we developers – as I’ll offer is true – want to work within our workflow committing, tagging, and knowing our applications will appear in test, development, QA, UAT, and production as we work.

Continue reading “Kubecon Day 2 Keynotes”