Jake Hemstad

> although we have created a specialized mod operator PYMOD in libcudf for compatibility with Python's rules for handling negatives "PYMOD" is a misnomer. It wasn't intended to be 100%...

Found the original conversation: https://github.com/rapidsai/cudf/pull/1985#pullrequestreview-248424619 > What's worse is calling an operation PyMod. It doesn't tell a user of the C++ interface what it actually means. In general, we should...

> It does indeed look like simply commenting out the `list_view` specialization of the code makes the struct code path faster. The overhead of constructing the Dremel data is negligible,...

> The new code path definitely adversely affects performance for primitive types. How much are we talking?

> have Thrust types in the public API like all of RAPIDS. We should just get away from doing this. I don't know of cases where we use anything other...

fwiw, the original impetus for this issue was due to mixing CUB versions in a C++ code using both libcudf and CUB headers. We definitely don't have any CUB types...

> With a solution to [NVIDIA/cub#545](https://github.com/NVIDIA/cub/issues/545) being merged, I think the best option for cudf is to patch our version of thrust. Can't we just use a version of Thrust...

> No released version of Thrust currently exists have the required changes. Once Thrust 2.1 has been released ( or the patches are back ported ) we can stop patching...

So Pandas expects division by zero to yield zero?

> As long as we're doing things like INT_POW could there be precedent to add this at the libcudf level? INT_POW is different. It's a distinct algorithm for doing the...