## Exponential Moving Average (EMA) Rates, part 1

I had been thinking about determining the average rate of occurrences over time of some observation. For example, you might like to measure how much traffic flows through a street throughout the day. Reporting the time that every single car goes by is very accurate, but not very useful. You might bin traffic into hours starting on every hour, but if there is a spike or sudden increase in the middle of an hour you might miss its significance. So, you'd like to see a graph that's smooth like an average but with more detail in time.

One approach is similar to the binning approach, but slide the hour-long window across the data by minutes. Doing this requires keeping the data around, and using each data point repeatedly. If you have a surge of one million cars in a few minutes, you need to use those million points in your calculations 60 times.

This behavior is similar to the Simple Moving Average (SMA). A SMA can easily be transformed into an Exponential Moving Average, which requires only the previous EMA and the new data point to calculate the new EMA. So, I decided to create an Exponential Moving Average Rate (EMAR).

Continue reading "Exponential Moving Average (EMA) Rates, part 1"

## The correct way to start an Exponential Moving Average (EMA)

The EMA is a very handy tool. It lets us calculate an average over recent data. But, unlike a Simple Moving Average, we don't have to keep a window of samples around—we can update an EMA "online," one sample at a time.

But the perennial question is: how do you start an EMA?

First, here are a couple of wrong ways.

Continue reading "The correct way to start an Exponential Moving Average (EMA)"

## Deciding once

In Fixing dispatch, we refactored some code that dispatched things from a switch-statement or cascading if-statements to dispatching by polymorphism.

This time, we'll refactor a different piece of dispatch in a completely different way, and cover another design principle.

## Effective practice

As a musician, I began to watch the different ways that people practice music. I noticed a pattern there, and started seeing the same pattern whenever people practice.

Our psychology makes it very easy to slip into practice ineffectively. On the other hand, simply understanding what and why makes it easy for you to have really effective practice.

It's the difference between mastering something versus just wasting your time. And you can boil it down to just one simple rule.

## Fixing dispatch

A fun thing about refactoring code is that after one refactor is finished, the next candidate is easier to see.

In An abstraction gone wrong, we refactored the state variable of a simple tokenizer from an integer into an object. Now that that's done, another problem is staring at us in the face. It's in this code:

if (state == INITIAL) {
// ...
} else if (state == IN_NUMBER) {
// ...
} else if (state == IN_STRING) {
// ...
} else if (state == AFTER_STRING) {
// ...
} else if (state == ESCAPING) {
// ...
}