The code for the Freedman Diaconis binwidth estimator is here:

Aside from cruft, the function is two lines long:

iqr = np.subtract(*np.percentile(x, [75, 25]))
return 2.0 * iqr * x.size ** (-1.0 / 3.0)

This is pretty much identical to your method, and yields the same result. However, some additional magic happens under the hood in _get_bin_edges to turn this width into bin edges:

1. First, we round the width up to the nearest bin count that fits the range exactly:

   numpy/numpy/lib/histograms.py

   Line 411 in f36e940

   n_equal_bins = int(np.ceil(_unsigned_subtract(last_edge, first_edge) / width))

   This is equivalent to int(np.ceil(np.subtract(9, 1) / 3.8459988541530894)) in your case, so the result is 3 bins. Given that the original bin width would require 2.080083823051904 bins to fit across the range, this seems reasonable.

2. Then we generate the edges to fill the range exactly:

   numpy/numpy/lib/histograms.py

   Line 446 in f36e940

   bin_edges = np.linspace(

As you can see, it is the rounding step that is responsible for the difference in results. So your observation of the difference is correct, but the code is using the same result as yours along with some additional transformations. We could argue ad nauseum about rounding vs rounding up or rounding down, but the result would never match the optimal bin width in any case. One other alternative I can think of is keeping the optimal width, and setting the start/end points to fully contain the range. This would result in biases of the edge bins, however, which is generally undesirable.

Hey, thanks for getting back to me! Your explanation makes a lot of sense.

I see what the code is doing now, and it makes sense. I guess I just find it surprising that if you specify the bin width method, the produced bin width is not what the formula in the documentation. However, if the code is behaving as expected I guess it's best to close the issue.

It may be worth documenting this somewhere. A sentence like "The actual number of bins is always chosen to divide the range into an integer number of bins that is at least as large as the estimate.", or something to that effect in histogram. Would you like to open a PR to include that, or would you like me to do it?

I can give that a go - thanks!

You can now close this issue. I suspect it's going to be a handy source/reference for places like Stack Overflow. Nice work!

Cool, thanks for the help!