hexbin

Builtin index · Plotting

hexbin(x, y, [bins=], [colormap=], [mincount=])

Input: x, y, bins, colormap, mincount · Output: no output

What it is

The plane tiled with hexagons, each shaded by how many points fell in it — for the case a scatter cannot do, where past a few thousand marks the picture saturates into a blob. x and y are equal-length numeric Vecs giving the point coordinates; bins= (number, default 30, minimum 2) is how many hexagons span the x range; the row count follows from it at three quarters of that, which is the spacing that makes the offset rows interlock rather than overlap; colormap= (string) names the shading ramp; mincount= (number) leaves a cell unpainted until at least that many points land in it, which is what keeps a sparse tail from covering the plane in near-empty hexagons. Hexagons rather than squares because a hexagon's centre is equidistant from all six neighbours, so a cell's count does not depend on which way the data runs.

Overloads

One call shape — this function is not overloaded.

Examples

No documentation example calls this form yet. The Plotting chapter is where one belongs.

How it works

raincloud(data) / raincloud(data1, data2, ...) (Allen et al. 2019) -- one group per argument at x = 0, 1, 2, ...: a Gaussian KDE "cloud", a boxplot, and jittered raw points ("rain"). raincloud(a, b, ...) and violin(a, b, ...): the same three things computed from each group -- a kernel density, a Tukey summary, and the raw points -- arranged two ways. A raincloud leans a half-density off its box and shows the samples beside it; a violin mirrors the density into the closed symmetric shape and shows the summary alone. One code path deliberately: they answer the same question, and two implementations would be two chances to disagree about what the density of a given sample is. hexbin(x, y, [bins=], [colormap=], [mincount=]) Hexagons on an OFFSET grid: every other row is shifted half a cell, which is what makes each centre equidistant from all six of its neighbours. On a square grid a cell's count depends on which way the data happens to run -- a diagonal ridge lands differently than a horizontal one -- and that is an artefact of the binning, not a feature of the data.

From the note above this builtin in the interpreter, where the reasoning was written down as it was built.