Record Float64 values in HDR

[jaxonpickett]

Is there any particular reason why int64 was chosen over float64 for the type of recorded values? I am interested in incorporating the HDR into our existing metrics pipeline, but our pipeline transmits metrics as float64 type. If I forked this project and refactored to use the float, are there potential issues that perhaps are not immediately obvious? I'm just wondering if int64 was chosen for a very specific reason, or was a somewhat arbitrary decision. Worst case scenario I can update my pipeline services to convert from float to int and back again, but I would really like to avoid that. The histogram I am most familiar with is implemented in Prometheus and accepts float64 as value.

[ahothan]

Scrubbing standing issues...
Original requirements was for implementing hdr for latency which is stored as usec or nsec, and hence no need to use fp.
I think moving to fp might work although there are quite a lot of internal calculation on the values and there could be unexpected issues.
In your specific use case, what kind of unit do you have as fp? Can it be converted to smaller resolution (eg. fractional sec to nsec)?