I have a use case where I am spawning several producer goroutines that will be emitting latency metrics. Is it safe to expose a single tdigest object globally and have it be written to by each of these producer goroutines? I'm concerned about possible data races and also if there will be significant overhead due to producers waiting to acquire locks to write to the tdigest. Thanks!

Try adding fmt.Println(digest.CDF(0.71875)) to the end of TestGammaDistribution. I'd expect a number between 0 and 1 (closer to 1) but i get 49999.091465195546.

The issue #12 leads me to believe there might be even more pathological scenarios, so it's a good idea to take a close look at https://github.com/tdunning/t-digest/tree/master/quality and see what can be learned and reused.

It looks like original Java implementation writes 2 doubles after the encoding code. But Go port have nothing like that. Am I right to assume that those 2 encodings are incompatible and there is nothing to do about it?

These are the things planned so far:

• Make API consistent (single type for integers, single type for floats, compression configuration (accepts uint, sets float))
• Change default rng to be a local one (ref #29)
• Change internal counts to uint64 from uint32

t.Summary = newSummary(estimateCapacity(t.Compression), oldTree.Resolution)

# missing
t.Count = 0

t.Add also does t.Count += count, so t.Count is doubled on each TDigest.Compress

The AVL iteration loop (spawned from t.summary.Iter()) creates a goroutine; terminating the loop early (via break) leaves a goroutune blocked on sending to the current iteration channel.

There is no way I can see with the current AVL library to terminating an iteration early; perhaps switching to a different key/value data structure or implementation would help.

Working on #12 I stumbled on several things I would like to change which would trigger api breakage (forcing a 2.0.0 release):

• Remove the centroid abstraction: it's useless in its current encantation, however it's exposed publicly
• Get rid of all explicit panic()s (the most annoying one is gone on avl-wip already)
• Configurable RNG (mostly to benefit testing)

Other things that would be nice to work on and don't necessarily force a major release:

• (Dropped from v2: doesn't seem worth it) More deterministic tests: currently running them with -run TestName yields different (but still correct of course) results when compared with running them all.
• Test different distributions: requires writing some code or adding test-only dependencies
• (Dropped from v2: blocked) Sync up merge formats after the reference implementation changes (issue87)
• Investigate prefix sum optimization ideas: using a binary indexed tree or a plain cache should improve speed noticeably without a big memory cost: d89c9f2

I am trying to run the Example Usage code with the purpose of understanding how the data-structure works but it throws up multiple-value tdigest.New() in single-value context error.
why would this be happening?

Following the discussion on PR #11 I've isolated a tiny pathological sample:

t := New(10)
data := []float64{0, 279, 2, 281}
for _, f := range data {
    t.Add(f, 1)
}
fmt.Println(t.Quantile(0.25))

Which yields -67.7500. In hindsight, this outrageously wrong number should have raised a major red flag in my head already, but when comparing to Java this gets even more obviously wrong:

public class Ughhh {
    public static void main(String[] args) {
        TDigest t = new AVLTreeDigest(10);
        Arrays.asList(0, 279, 2, 281).forEach(t::add);
        System.out.println(t.quantile(0.25));
    }
}

Prints out 1.0 😅 (Note: before the min/max patch on tdunning/t-digest@89bb394 it yields 1.5).

Do you plan to add Go Modules support
When I am using this module, it is showing it as incompatible module

github.com/caio/go-tdigest v3.1.0+incompatible

Seems like there are some optimizations in https://github.com/honeycombio/go-tdigest that might be nice. I'm not sure if @ianwilkes was planning on upstreaming them.