Is the numerical problem the diff? Would it make sense to just convert the numpy bin edges to float64 before the diff?

Is the numerical problem the diff?

Hard to say. But the problem is that one does quite a bit of computations and at some stage there are rounding errors that leads to that there are overlaps or gaps between edges. So postponing diff will reduce the risk that this happens (on the other hand, one may get cancellations as a result, but I do not think that will happen more now since the only things we add here are about the same order of magnitude).

Would it make sense to just convert the numpy bin edges to float64 before the diff?

Yes, or even float32, but as argued in the issue, one tend to use float16 for memory limited environments, so not clear if one can afford it.

Here, I am primarily trying to see the effect of it. As we do not deal with all involved computations here, some are also inbar/barh, the better approach may be to use a flag, "fill", or something that makes sure that all edges are adjacent if set (I'm quite sure a similar problem can arise if feedingbar-edges infloat16 as well.

It seems like we do not have any test images that are negatively affected by this at least... But it may indeed not be the best solution to the problem.

Ahh, but even if the data to hist isfloat16, the actual histogram array doesn't have to be that... And that is probably much smaller compared to the data. So probably a simpler fix is to change the data type of the histogram data before starting to process it...

I think you just want another type catch here (I guess I'm not sure the difference betweenfloat and"float64"), or at least that fixes the problem for me.

diff --git a/lib/matplotlib/axes/_axes.py b/lib/matplotlib/axes/_axes.pyindex f1ec9406ea..88d90294a3 100644--- a/lib/matplotlib/axes/_axes.py+++ b/lib/matplotlib/axes/_axes.py@@ -6614,6 +6614,7 @@ such objects             m, bins = np.histogram(x[i], bins, weights=w[i], **hist_kwargs)             tops.append(m)         tops = np.array(tops, float)  # causes problems later if it's an int+        bins = np.array(bins, float)  # causes problems is float16!         if stacked:             tops = tops.cumsum(axis=0)             # If a stacked density plot, normalize so the area of all the

I guess I'm not sure the difference between float and "float64"

Numpy accepts builtin python types and maps them to numpy types:

https://numpy.org/doc/stable/reference/arrays.dtypes.html#specifying-and-constructing-data-types
(scroll a bit to "Built-in Python types").

The mapping can be platform specific. E.g.int maps tonp.int64 on linux butnp.int32 on win.
float maps on x86 linux and win tonp.float64. But I don't know if that's true on arm etc.