@open-telemetry/specs-metrics-approvers this is ready for review.

@yzhuge and @oertl please review

FYI I have posted reference implementations that calculate bucket indexes described by the formulas here. These were captured from the review thread of open-telemetry/opentelemetry-proto#322 here, now available:
open-telemetry/oteps#179

@jmacd all looks good now.

@jmacd "the lower-boundary of index -68 cannot be represented using a double".
In negative scales, the lowest bucket may be a "partial bucket" (partially representable by "double" range).
An implementation's lower bound function will need to guard against floating point underflow. In NrSketch, I have https://github.com/newrelic-experimental/newrelic-sketch-java/blob/main/src/main/java/com/newrelic/nrsketch/indexer/ExponentIndexer.java#L43

Similarly, to be bullet proof, we need guard against overflow at the high end of "double":
https://github.com/newrelic-experimental/newrelic-sketch-java/blob/main/src/main/java/com/newrelic/nrsketch/indexer/ScaledExpIndexer.java#L114

Not sure it is worth mentioning such extreme cases in the spec though. Maybe it is, spec has to be bullet proof.

"Should the producer bother to check that an index can be reverse-mapped before using it?"
I think producer should still map it to the lowest (partial) bucket. Its other choices are: round off to zero; throw an exception. None is great.

And I assume you are talking about the exponent extraction method. The log method generally does not work well in the subnormal range. I had to skip it in subnormal tests (https://github.com/newrelic-experimental/newrelic-sketch-java/blob/main/src/test/java/com/newrelic/nrsketch/indexer/BucketIndexerTest.java#L400)