Poisson Distribution for Generating Counts

Imagine recording, for thousands of users, how many times each one logged in during a month. Most users log in a handful of times, a few log in many times, and nobody logs in a negative number of times. This kind of feature is called count data, and it shows up constantly in real measurements. Counting how often something happened is one of the most common ways data is produced, so learning to recognize count data and to predict its shape is a practical skill for anyone preparing data for a model.

This article moves from observation to explanation. You will first trace a short counting routine line by line to see where a tally can silently go wrong, then examine why count histograms look the way they do, and finally see why a log transformation is often applied before modeling.

The first property, integer values, means the feature can take only a discrete set of possible numbers. The possible values are 0, 1, 2, and so on, with no fractional counts between two whole values. The second property, that counts are never negative, means the lowest possible value is a hard floor, usually zero.

These two properties have consequences for shape. Together they often produce a distribution that is lopsided: a crowd of small values, a steady fall-off as values grow, and an occasional very large value far out on the right. A feature that is merely a whole number is not automatically count data, but a feature that records how often something happened, and that cannot dip below zero, has the structure described here.

Counting code fails quietly more often than it fails loudly, so it helps to know where to look when a tally disagrees with expectation. The routine below is a generated illustration of the pattern described in the source: it creates a list of slots sized from the largest value, and then uses each observed value directly as an index into that list. This assumes every value is a non-negative integer. The indexing step is where that assumption can break, so that is where a trace should focus.

The source's synthetic dataset was built to mimic counts found in real settings. It starts with values drawn from a standard normal distribution, which are bell-shaped. Each of those values is then passed through the exponential function and scaled by 10. The scaled result is used as the rate for a Poisson distribution, and each final count feature entry is a random draw from a Poisson distribution with that rate. A Poisson distribution is a probability distribution used to model count data, so the final features are counts even though an intermediate step was bell-shaped.

This sequence shows that the shape of a feature is not fixed by its underlying meaning alone. The bell-shaped latent values are pushed through an exponential, which stretches the upper end, and then the discrete Poisson sampling converts them into integers. The result has the integer-valued, non-negative, skewed character described earlier. The first ten entries of the first feature are all integers and all positive, yet reading them one by one reveals no clear pattern.

NumPy's bincount function is the tool the source uses for this job. It counts how many times each non-negative integer appears in an array and returns a sequence in which position k holds the number of appearances of the value k. Because positions start at zero, the first entry always refers to the value zero, even when zero never occurs in the data. That detail is the source of many off-by-one confusions, so keep it in mind when reading any bincount output.

In the source's tally for the first feature, the lower values are the most frequent, the counts for higher values fall off quickly, and the long right-hand tail still contains a few large values. The source notes one especially high value that appears only twice. The overall picture is a sharply peaked, right-skewed histogram. A histogram is the natural way to view count data for this reason: it turns a long list of integers into a picture of how frequently each value occurs. When you visualize count data, the horizontal axis should show the count values themselves and the vertical axis should show how often each value occurred.

Before a model learns anything, the features it receives have a shape, and that shape can make learning easy or hard. Many modeling methods work best when each input feature, and in regression also the target, is loosely Gaussian distributed. In practice this means that if you draw a histogram of one feature, it should look something like the familiar bell curve. Real measurements rarely arrive in that form, so a common job of a data practitioner is to reshape features before modeling them.

The contrast between a raw count histogram and a bell curve is the central motivation for transforming count features. Count features, as generated and tallied, depart from the bell shape in predictable ways. The gap between the two is what a transformation is meant to close.

The source describes using transformations like log and exp to move a feature toward a Gaussian shape, and it calls this approach hacky but simple and efficient. The transformation is especially useful for integer count data, because counts pile up at small values and stretch out at large ones, and a logarithm compresses that stretch. The exponential function is the mirror image of the logarithm, which is why both appear in the source's workflow: exp appears when the data is generated, and log appears when the data is reshaped toward a bell curve. Applying $\log(x)$ to a count compresses the long right tail, while $e^{x}$ maps a logged value back to the original count scale.