The distribution panel on the Performance page has a small control most people click without thinking about it. Four buttons labelled 10, 20, 30 and 50, which set how many bars the histogram is drawn with. It looks like a display preference, like choosing a chart colour. It is not. On a sample this size it changes what the chart appears to say, and if you click through all four settings before deciding which one to believe, you have already lost the argument with yourself.
On the capture I am working from the panel header reads n equals 87, mean equals -0.53, median equals 0.00, and the PnL percent histogram is drawn at 20 bins running from about -17.34 on the left to about 1.00 on the right, with the count axis topping out at 66. Those numbers are enough to work out exactly what each of the four settings does to the picture, without clicking anything.
The arithmetic of the four settings
The data spans roughly 18.34 percentage points, from -17.34 to 1.00. Divide that span by each setting and you get the width of one bar.
- 10 bins gives bars about 1.83 points wide, and 8.7 trades per bar on average.
- 20 bins gives bars about 0.92 points wide, and 4.4 trades per bar on average.
- 30 bins gives bars about 0.61 points wide, and 2.9 trades per bar on average.
- 50 bins gives bars about 0.37 points wide, and 1.7 trades per bar on average.
Those averages are misleading in a specific and important way, because the distribution is nowhere near uniform. At the 20-bin setting one bar holds 66 of the 87 trades. That leaves 21 trades to be spread across the other 19 bars, which is about one trade each.
Read that again, because it is the whole point. Outside the central spike, every bar you are looking at represents one trade or two. The tail of that histogram is not a distribution, it is a list of individual trades drawn as rectangles. Push the setting to 50 and it gets worse: 21 trades spread over 49 bars, most of which are empty, and the eye reads the resulting picket fence as a wide spread of outcomes.
What three standard rules say to use
Choosing a bin count is an old problem with several published rules of thumb, and the useful thing about them is that they are arithmetic you can do on your own sample in ten seconds. All of them are functions of n alone. For n equals 87:
The square root rule says use about the square root of the sample size, which is 9.3, so 9 or 10 bins.
Sturges suggests 1 plus the base-two logarithm of n, which works out to 1 plus 6.44, or about 8 bins.
The Rice rule suggests twice the cube root of n, which is 2 times 4.43, or about 9 bins.
Three different rules, three answers between 8 and 9. The panel offers 10 as its smallest setting, and 10 is the only option on the control that is anywhere near what any of them recommend. Every other setting is drawing more bars than a sample of 87 can support.
There is a fourth rule worth knowing, Freedman-Diaconis, which is better than the other three because it uses the spread of the data rather than only the count. It sets bar width at twice the interquartile range divided by the cube root of n. You cannot compute it from the panel header, because you need the quartiles, but you can compute it in thirty seconds from the exported CSV. On a distribution as tightly clustered as this one, with a median of 0.00 and most of the mass in one bin, the interquartile range will be small and Freedman-Diaconis will call for narrow bars over the middle. That is a real disagreement with the other three rules, and it exists because the sample is lopsided rather than because one rule is wrong.
How the same trades tell four different stories
Here is what actually changes as you click through, on this sample.
At 10 bins the central spike absorbs even more of the sample, since the bar covering zero gets twice as wide. The tail collapses into two or three short bars. The story the chart tells is "one enormous cluster at zero and a small tail", which is an accurate summary of a book with a median of 0.00 and a mean of -0.53.
At 20 bins, the setting in the capture, you get the same spike plus a scattering of one-trade bars to the left. The eye now reads texture in the tail, and there is no texture there. Twenty-one trades cannot form a shape.
At 30 and 50 bins the spike itself starts to split. This is the setting where people convince themselves they have found a bimodal distribution, or a cluster of losses around a particular size. Both are artefacts of where the bin edges happened to fall relative to a pile of trades near zero. Move the edges by half a bar width and the second peak disappears.
None of these renderings is false. They are all the same 87 numbers. But three of the four invite you to read structure that a sample of 87 cannot establish, and only one of them is close to what the standard rules recommend.
The rule I use and why it is boring
Set it to 10 and never touch it again.
Two reasons. The first is the one above: 10 is the only setting on this control that is close to what the sample size supports. The second matters more over time. A metric you re-render differently each month is a metric you cannot compare month to month, and the value of this panel is almost entirely in comparison. This month against last month, live against paper, one venue against another. A change in shape only means something if the rendering was held constant, and the fastest way to fool yourself is to change the bin count in the same session you changed something about how you trade.
Then read the extremes numerically rather than visually. The sentence that matters is not "the tail looks fatter this month". It is "six trades finished worse than -10 percent this month against two last month". That sentence comes from counting rows in the export, it is true at any bin setting, and it survives being repeated to someone else.
Two things on this panel that are not the bin control
While you are in here, two other observations from the same capture are worth carrying away.
The first is that the R-multiple view reports the same n, the same mean of -0.53, the same median of 0.00 and the same axis extents as the PnL percent view. Those two metrics answer different questions, PnL against notional and PnL against risk taken, so if they render identically on your account it is worth resolving what your R is being computed against before you lean on that view. The export will tell you in a minute. I am not going to guess at it from the outside.
The second is a general caution about this whole page. The same statistic can appear on more than one Blockcircle surface with different values, because a figure computed over trade records and a figure computed over an equity curve are answering different questions even when both are computed correctly. When you take a number off this page, write down which panel it came from, which account scope was selected and which date range was active. That habit costs you five seconds and it is the difference between a note you can act on next month and a note you have to redo.