Basically, PCA (Principle Component Analysis) finds projection axes based on total population variance. Because that is not correlated with classes, that means that adding PCA into your classification pipeline is essentially adding a random variable. Or, more exactly, it's like using a set of random, orthogonal projection axes.

Here's a simple example of PCA making classification harder…

Sometimes we end up executing some asynchronous function several times in a row, but we need only the results of the last call. The difficulty is that some earlier invocations may finish after the latest. I encounter this most often in Javascript, when I call an API in response to ongoing user input, like for looking up an address. While debouncing can help reduce this problem (and should be done anyway to lighten the load), it does not eliminate the problem.

A simple way to do this is to use a counter to keep track of each request, and only process a response if it's newer than any other processed so far.

Averages are used, in some form or other, and many machine-learning algorithms. Stochastic gradient descent is a great example of an average in disguise, thin though it may be.

Picking the right kind of average can be critical. As learning algorithms explore sub-optimal choices, the resulting negative impact on backed-up state values can persist over epochs, hampering performance. Alternatively, some kinds of average don't converge, preventing the algorithm from settling into optimal outcomes.

Here, I officially release a paper on a particular kind of average that's adaptable like an exponential moving average, but has guaranteed convergence like a simple average.

Implementing a Q-table reinforcement-learner is in many ways simple and straight-forward and also somewhat tricky. The basic concept is easy to grasp; but, as many have mentioned, reinforcement-learners almost want to work, despite whatever bugs or sub-optimal math might be in the implementation.

Here are some quick notes about the approach I've come to use, specifically about action-selection (e.g. epsilon-greedy versus UCB) and managing learning-rates. They've helped my learners converge to good strategies faster and more reliably. Hopefully they can help you, too!

I recently worked on a small project simulating random events that were far too numerous to enumerate. In such cases, every bit of speed matters.

The project in this case was similar to determining likelihood of five-card Poker hands in seven-card draws.

Simulation of shuffling the deck and drawing cards can take a large part of the runtime if not done well, but there's a trick that makes it almost trivial.

Sometimes, you need a list of random numbers that sum to a known constant. There's a known algorithm to provide this list of numbers with the proper distribution, but a straight-forward implementation may give a list that doesn't sum exactly to the desired constant because of rounding error.

This article describes the basic algorithm, why the rounding error happens, and the solution.

In some sense, random numbers uniformly-distributed in the range \([0, 1)\) are the easiest class of random number to generate.

Because of the internal representation of floating-point numbers, all you need to do is fill the significand with random bits, set the exponent to -1, and the sign bit to positive.

Some language run-times do this better than others.

This article shows how to check your run-time, and how to fix it.

Let's Encrypt now supports wildcard certificates. To confirm DNS control, they support several different DNS providers and dynamic DNS protocols, but they don't yet have a plugin for tinydns by DJ Bernstein.

Luckily, the excellent designs of both certbot and tinydns make it very easy to support on your own.

In Theory of Games and Economic Behavior, von Neumann discusses solutions to some kinds of zero-sum four-person games. See section 37.4.2, page 317. There, he finds that one set of imputations is incomplete, and must have at least another imputation added to it. He writes that [it] seems very difficult to find a heuristic motivation for the steps which are now necessary before giving the imputation as:

The situation is unusual in that the first three players have formed a coalition against the fourth. So, why does the third player have the same loss as the fourth? This is the heuristic that von Neumann didn’t provide, and he concludes by saying only that [if] a common-sense interpretation of this solution… is wanted, … it seems to be some kind of compromise between a part (two members) of a possible victorious coalition and the other two players.

However, there’s an intriguing possibility.

In the last post, we created an online implementation of an EMA to measure the rate of a Poisson event. However, it has the “warm-up” period seen in most EMA implementations.

This time, we’ll correct that. The technique is similar to what I wrote in The correct way to start an Exponential Moving Average (EMA).

In the last post, we simulated some Poisson data and then verified it by looking at its histogram and some descriptive statistics. We also built a basic sliding-window implementation and graphed its output.

To continue on, we’ll need to build a more realistic implementation, along with a method to feed it the simulated events. With that in hand, we’ll build an EMA function specialized for Poisson events.

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).

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.

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.