Numbagg

0.6.8 contains mostly internal changes — the initial benchmarking approach is expanded to all functions and displayed in the new Readme. The same framework is now used to test all functions. We also ensure the functions don't emit warnings when handling expected inputs in our tests.

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.