Closed tylertreat closed 9 years ago
(Sorry, just realized I hadn’t responded to this!)
This looks good to me except for the change to New
. The only reason sigfigs
is stored as an int64
internally is to avoid a handful of type conversions. The use of a 64-bit value for an argument which is typically in [3,5]
exposes a purely internal concern via the API, which I’d rather not do.
Other than that, I’m happy with the PR. Thanks!
And fixed.
Awesome! Thank you!
Thanks for the golang port, super useful.
This is a stab at addressing what was discussed in issue #1. I think the consensus from that discussion was to keep the API simple. Any kind of
Histogram
serialization should be deferred to users of the library, but a way to export a view of theHistogram
should be provided.This introduces a
Snapshot
which is produced onExport
. This allows users to do what they want with it and later reconstruct aHistogram
from it usingImport
. Another item is theEquals
method which is used to compare aHistogram
for equality.Also changed
New
so that the sigfigs argument is anint64
, which reflects the type on the underlyingHistogram
.