|Summary:||Modulo Operator for 1D|
|Component:||Core - general||Assignee:||Nobody <eigen.nobody>|
|Severity:||Feature Request||CC:||chtz, gael.guennebaud, jacob.benoit.1, rmlarsen|
|Bug Depends on:|
Description Pantelis 2012-05-24 20:15:44 UTC
Hello, would it possible to have a modulo (%) operator on Array objects? All best, Pantelis
Comment 1 Rasmus Munk Larsen 2019-03-18 22:20:31 UTC
Gael, Christoph, what are your thoughts about this? In the tensor library we have defined operators scalar_fmod_op, scalar_mod_op, and scalar_mod2_op: https://bitbucket.org/eigen/eigen/src/default/unsupported/Eigen/CXX11/src/Tensor/TensorFunctors.h#lines-21 Should we move that to core? fmod is not trivial to implement correctly, so perhaps we could defer vectorizing it, but having a vectorized integer modulo operator seems like low-hanging fruit.
Comment 2 Rasmus Munk Larsen 2019-03-18 23:41:21 UTC
The lack of vectorized division on x86 makes it not very attractive, of course.
Comment 3 Christoph Hertzberg 2019-03-19 08:36:34 UTC
Why not. I think the easiest way to vectorize this for integers on x86 is to cast to double, divide, and cast back (and calculate the remainder). We could also vectorize pdiv<int32> that way. And in theory, a constant divider could be vectorized by some multiplication and shifting and subtracting. For floats/doubles I guess it is relatively simple to get a "good-enough" solution. But getting things like `fmod(MAX_FLOAT, 99.f)` accurate is not trivial, of course. We could implement something which works correctly in most cases and falls down to a non-vectorized path otherwise (similar to our range-reduction in sincos). API-wise, I'm not sure if we should overload `%` for that or just provide functions (also with one argument a Scalar): mod(Array,Array), Array::mod(Array), Matrix::cwiseMod(Matrix) I'm preferring the latter, since % is not overloaded for float and double either. And overloading it only for Array<int> seems unnecessarily complicated.
Comment 4 Nobody 2019-12-04 11:40:55 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/467.