Numbagg

0.6.7 removes the temporary patch for the `int8` issues we experienced previously in grouping functions, replacing it with something more robust. Specifically, when there are a very large number of items in a group and `labels` has a very small dtype, `labels` is cast to a higher dtype.

Following closely on the heels of 0.6.5, 0.6.6 works around another rare but serious bug with `int8` types. We now coerce all `int8` label arrays to `int16`.

Many thanks to dcherian for the report.

0.6.5 works around a rare but serious bug — when a labels array with `int8` type is used in a group function, numbagg can return an incorrect result. The bug requires the array to be a specific size. The currently implemented solution is a workaround rather than an understanding of the underlying issue. Check out https://github.com/numbagg/numbagg/issues/211 for more details.

0.6.4 fixes a small bug — the value for the `window` argument for rolling methods couldn't be equal to the axis length.

Numbagg will now compile with`mode="cpu"` if it detects that it's being run in a `ThreadPoolExecutor`. Previously, the default `mode="parallel"` could cause numba to abort the python program within that context.

Note that running in a multi-_process_ context retains `mode="parallel"`, so the new behavior should only be slower in infrequent cases, such as a local dask multi-threaded executor.

I'm not completely confident this is the globally optimal solution, so this may evolve. https://github.com/numba/numba/issues/9288 has more context.

0.6.2 allows grouping functions to take a wider range of `int` types as labels. Thanks to dcherian for the contribution.