REGR: Series.__mod__ behaves different with numexpr
- [ ] closes #36047
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

will add tests if reverting change in #30147 without any new test failures see https://github.com/pandas-dev/pandas/pull/30147#discussion_r371020296 @simonjayhawkins example with rmod:

```
In [41]: pd.Series([-5] * 10001) % 24  
Out[41]: 
0       -5
1       -5
2       -5
3       -5
4       -5
        ..
9996    -5
9997    -5
9998    -5
9999    -5
10000   -5
Length: 10001, dtype: int64

In [42]: -5 % pd.Series([24] * 10001) 
Out[42]: 
0       -5
1       -5
2       -5
3       -5
4       -5
        ..
9996    -5
9997    -5
9998    -5
9999    -5
10000   -5
Length: 10001, dtype: int64
```

But not sure how it comes this also regressed compared to 1.0, as we already had `rmod: "%",` before as well (maybe in the end rmod also ends up calling mod ?) (sorry, see now you only asked about (r)floordiv) > But not sure how it comes this also regressed compared to 1.0, as we already had `rmod: "%",` before as well (maybe in the end rmod also ends up calling mod ?)

rmod was already failing, so not a regression. I couldn't find any issues so probably not so used so much, considering we have had 2 reports on the mod issue in a short space of time. I don't see any failure here:

```
In [4]: pd.__version__                                                                                                                                                                                             
Out[4]: '1.0.3'

In [5]: pd.Series([-5] * 10001) % 24                                                                                                                                                                               
Out[5]: 
0        19
1        19
2        19
3        19
4        19
         ..
9996     19
9997     19
9998     19
9999     19
10000    19
Length: 10001, dtype: int64

In [6]: -5 % pd.Series([24] * 10001)                                                                                                                                                                               
Out[6]: 
0        19
1        19
2        19
3        19
4        19
         ..
9996     19
9997     19
9998     19
9999     19
10000    19
Length: 10001, dtype: int64
```

and both are failing on master for regressions, i check against 1.0.5.

```
>>> pd.__version__
'1.0.5'
>>> -5 % pd.Series([24] * 10001)
0       -5
1       -5
2       -5
3       -5
4       -5
        ..
9996    -5
9997    -5
9998    -5
9999    -5
10000   -5
Length: 10001, dtype: int64
>>>
```

i'll try to find the cause of that regression. it was indeed working on 0.25.3 also. Whoops, I simply did not have numexpr installed in my 1.0 environment .. > Whoops, I simply did not have numexpr installed in my 1.0 environment ..

And I didn't in my 0.25.3! :smile: Optional dependencies used in core operations ... :-) 

Anyway, rmod is less used, so most important is fixing mod itself, which is undoubtly a regression > Anyway, rmod is less used, so most important is fixing mod itself, which is undoubtly a regression

my plan for this PR was simply to revert the change the caused the regression.

I not yet looked, but there may be special handling which is why floordiv and rfloordiv and not affected.

I will add tests for all 4 ops and xfail the rmod one and can then look to a proper fix (which could also be backportable of course)  Sounds good! unrelated failure (also on #34918) this looks ready @simonjayhawkins  (non-withstanding your comment above, which looks separte). not worried about the single failure which is old on travis. Not quite ready. review request https://github.com/pandas-dev/pandas/pull/36552#discussion_r493831661 remains outstanding.

I can't block by requesting changes on my own PR, moving to 1.1.4 so release note needs to be moved. closing for now instead. Will re-open after 1.1.3 release.

I've started the final release readiness checks. merging now would require going back to square one. @simonjayhawkins since this is basically ready, and fixing a serious regression (silently wrong result), I would still include it if possible. 

I think the only outstanding request was to have a more manual test checking correctness? That can certainly be left for a follow-up PR and shouldn't block 1.1.3 (we also didn't have such test now, so I mainly see this as a nice-to-have) Yeah a couple of reports about this. so getting this in would be good. (I closed this since often never seem to get round to nice to haves!) reopening to check ci status lgtm merge when ready (ignore the arm failure) @meeseeksdev backport 1.1.x