Feature request: support floating-point numbers

[justinlovinger]

Feature request: support floating-point numbers

See #91,

Floating point values can be supported, but they are basically a completely separate implementation that wraps an inner integer-based histogram. I'd be neat to port DoubleHistogram to Rust as well, but unfortunately it's a larger effort that I don't have time for myself at the moment. If you want to give it a try, I'd be happy to try and review? It should be a fairly straightforward translation of the Java version I linked above! I wonder if we may even be able to have a single Histogram type by providing inherent implementations for Histogram<f64>... Not entirely clear. Initially I'd just have a separate DoubleHistogram type.

If possible, I suggest implementing a type-generic histogram using num-traits.

[jonhoo]

It won't be possible to use num-trait here I don't think. Floats have to be handled fundamentally differently in HDR histograms is my understanding.

[justinlovinger]

But could all floats be handled with the same implementation? I meant something like RealHistogram<A: Real> or FloatHistogram<A: Float>.

Unfortunately, we cannot do the same for integer histograms because num-traits lacks an "integer but not real" trait to differentiate numbers with whole values from numbers with whole values and decimals.

[jonhoo]

Probably, though we could do that with a trait of our own that we implement just for f32 and f64 rather than going via num-traits. That way we're also reducing the breaking change hazard. Alternatively just implement for f64.

[justinlovinger]

If we implement our own trait, it will not work with other types implementing num-traits traits. For example, the application I want to use HdrHistogram for has a type wrapping f64. num-traits is already used extensively in the Rust ecosystem.

[jonhoo]

Yup, well aware of the implications. I'd want to see how the implementation ultimately pans out — I suspect going via num-traits might end up quite painful (vs just supporting f64), but happy to be proven wrong.