How to bin integral vs floating point correctly (precision issue and general question)

[emmenlau]

Dear @HDembinski and other authors, thanks for this awesome library. We have just started using it and the speed and versatility are impressive! We have a problem that manifests as a precision problem, but also shows a more general question.

The problem: We use the floating precision histogram to bin any kind of data. When we bin data (gray value camera images) of integer precision, we set lower and upper bound based on the data range to [min, max+1] and the number of bins to upper bound - lower bound. However there are sometimes cases where the numeric precision then leads to an empty last bin. This is due to rounding error, the values fall into max-1 instead of max. We checked and the bin index is then computed as (max-1).999... which finally resolves to max-1. Is there a good solution to this? It leads to confusion that the last bin is empty, and its also a bit problematic in writing tests.

The underlying question: We are not completely certain what is a "recommended" way to set histogram bounds for integral data space. Are there common guidelines? In floating point precision it is more understandable what data range is covered by each bin. But in integral space, it seems the value 0 could be best represented by bin [-0.5, 0.5) rather than the more obvious [0, 1). And help, links or pointers to documentation would be highly appreciated!

[HDembinski]

Thanks for the kind praise!

This is a recurring question and the standard answer is to use an integer axis for images. The regular axis is intended for real-valued input values from a continuous distribution, not for integer values.

So would using boost::histogram::axis::integer work for you? The integer axis uses exact integer arithmetic, and it is a bit faster than the regular axis, too.

If for some reason your input values are really floating point, you could add half the bin width to avoid the rounding errors. This is not an elegant solution, but it works.

This is also not an elegant solution, but you can even make your own axis class that does this step automatically. See https://www.boost.org/doc/libs/develop/libs/histogram/doc/html/histogram/guide.html#histogram.guide.expert.user_defined_axes for examples.

Basically, you would override theindex method of the regular axis, just like in the first example and add half the bin width to the input.

[HDembinski]

Come to think of it, you could also override the index method with something that rounds to the nearest integer.

[HDembinski]

The correct solution for this is for us to support boost::rational as the value type of the regular axis, see https://www.boost.org/doc/libs/1_77_0/libs/rational/rational.html, which would enable exact rational arithmetic. This does not work currently, but I can look into it.

[emmenlau]

Thanks a lot @HDembinski for the help!

What you say makes sense. We just looked at the integer axis, and it most likely would help. But I understand it can not be used with arbitrary bin counts, correct? This is not a huge impediment but it would be a bit sad.

Also the suggestion to add half a bin width would seem feasible and possibly a good idea! But then I guess we could not use the range-based fill() anymore which gives a very noticeable speedup?

Support for boost::rational sounds awesome, but would it introduce a significant slow-down?

[emmenlau]

Can I also ask a related question, in case you know: from a completely different point of view, is it sensible (or common) to shift the bin bounds by half a bin width down? We where considering this idea that for example bin 0 would have bounds [-0.5, 0.5) (for the example bins of size one). We see some potential benefits that (a) the integer or floating value falls in the center of the bin rather than the border, and (b) it compensates for aforementioned rounding issues. But we do not feel confident about this route if it is a very uncommon thing to do...

[HDembinski]

What you say makes sense. We just looked at the integer axis, and it most likely would help. But I understand it can not be used with arbitrary bin counts, correct? This is not a huge impediment but it would be a bit sad.

That is correct, axis::integer assumes that the "bin width" is 1. Perhaps we need another axis which allows integral multiples? What exactly do you need?

Also the suggestion to add half a bin width would seem feasible and possibly a good idea! But then I guess we could not use the range-based fill() anymore which gives a very noticeable speedup?

If you make your own axis which implements this hack, it will work with range-based fill().

Support for boost::rational sounds awesome, but would it introduce a significant slow-down?

I don't know, but I don't think the speed penalty would be terrible. It is not hard to implement, I think, so we should really support this and then I can check the benchmarks.

Yet another option that I forgot is to use the axis::variable, which you can construct in such a way that the bin edges are exactly where you want them to be. axis::variable is considerably slower than axis::regular, though.

[emmenlau]

Thanks a million for this fast and very helpful reply. I need to digest this new input a bit. Support for boost::rational sounds awesome, but your input has triggered new thoughts that require a bit more discussion on our side...

[HDembinski]

Once again thinking more about it and reading your original message again, is it correct that you only have an issue with the very last bin edge? Because then your need may be resolved if we implement #319

Boost.Histogram by default gives you under and overflow bins for each axis, and then the interval you specify is semi-open [a, b). This makes sense if your input is real-valued and drawn from a continuous distribution. In your case, you probably want a closed interval [a, b]. I plan for a while to support this if the user creates a regular axis with the overflow bin turned off.

[emmenlau]

Sorry for the delay in feedback. We've just tested #344 and it does solve a corner case for us, thanks for this. However the original problem still remains because we commonly do use overflow bins.

... is it correct that you only have an issue with the very last bin edge?

We have not observed the problem with other bins yet. But I am under the impression that this is just by chance. The problem should happen with any bin, when just by chance the raw index position falls by a margin below the lower bound of the "correct" bin.

We've discussed this internally and can't make up our minds between the multiple possible workarounds. What I see so far:

• using boost::rational: This seems very powerful and would certainly address the problem in a clean way. But it seems this also makes significant work in the implementation. Also, I could not find any benchmarks on boost::rational that would help to estimate the potential performance hit(?) It would be quite sad if it incurs a significant performance overhead.
• adding an epsilon of half a bin width in the computation of the index: This seems the easiest solution for us that should solve the problem in a generic way. I haven't tested, but the performance hit may also be negligible compared to the division. But its not entirely clear to me how this would be implemented in a clean way. If boost::histogram would handle integer binning internally with epsilon, and floating point binning without epsilon, it may add an ambiguity where the same value in different types is binned differently. On the other hand, if this is not handled inside boost::histogram, then how could we continue to use the range-based fill methods (that give the significant speed boost)?

[emmenlau]

After a longer discussion we are considering a third option, that I wanted to get your feedback on. The best of all worlds for us seems to be an axis that supports both integer and floating point and can automatically switch between the two. It should behave like the integer axis, as long as the bounds and the scale are (precisely) integral values. In this case, it correctly bins integer and floating point values by using the precise (and faster) integer arithmetics. Only when any of the relevant parameters (bounds or scale) is set to floating point, it automatically switches to floating point arithmetics.

This seems to bring a set of nice benefits, and we could not see any downsides (yet). Benefits:

• A single histogram instance gives the "perfect" integer arithmetics precision when legal, but also supports floating point arithmetics when needed. No need for the user to decide upfront. And it significantly reduces the risk of rounding errors.
• In many cases, this can give superior speed even for floating point histograms, just as long as their parameters coincide with integral parameters.

Did we overlook some obstacles here? What do you think?

[emmenlau]

Hi @HDembinski , sorry to bother you with this question again, but it would be great to get your feedback on the above implementation idea. We've implemented such an axis as a test (an axis that supports both integer and floating point precision, and automatically switches between the two, depending on the user parameters).
Does that seem reasonable to you? And would that be something that boost::histogram could support native (rather that our test implementation)?

[HDembinski]

Sorry for not responding earlier. I think as a practical fix, it is fine to just shift the bins by half a bin width if you are still considering this.

The axis that you mention, which uses exact integer arithmetic when everything is integral: this is already how floating point numbers with integral values work to my knowledge. Could you perhaps produce a small code example to show the wrong behavior and the expected?