mod seemingly dispatches to the rust remainder operator rather than the modulo operator

[deanm0000]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of Polars.

Reproducible example

import polars as pl
import numpy as np

x = 2.1
df = pl.DataFrame({'x':x})

print(x % 2) # Prints 0.1
print(np.mod(x,2)) # Prints 0.1
print(df.select(pl.col('x').mod(2))) # Prints 0.1

x = -.1
df = pl.DataFrame({'x':x})

print(x % 2) # Prints 1.9
print(np.mod(x,2)) # Prints 1.9
print(df.select(pl.col('x').mod(2))) #Prints -0.1

This originated at this SO question

Issue description

I found this which confirms BallPointBen's assertion that there's a mismatch in operators.

Expected behavior

mod should match the python % operator and np.mod

Installed versions

--------Version info---------
Polars:              0.18.15
Index type:          UInt32
Platform:            Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.31
Python:              3.10.12 (main, Jun  7 2023, 19:32:10) [GCC 10.2.1 20210110]

----Optional dependencies----
adbc_driver_sqlite:  <not installed>
cloudpickle:         <not installed>
connectorx:          0.3.1
deltalake:           <not installed>
fsspec:              2023.6.0
matplotlib:          <not installed>
numpy:               1.25.2
pandas:              2.0.3
pyarrow:             12.0.1
pydantic:            2.1.1
sqlalchemy:          <not installed>
xlsx2csv:            0.8.1
xlsxwriter:          3.1.2

[orlp]

I much prefer Python's definition of mod to Rust's, so I'm all in favor of changing it to match Python's behavior.

However this also means we must update integer division to be consistent with it. The identity (a / b) * b + (a % b) == a must always hold.

[ritchie46]

There has been a discussion about this before where we decided we keep true to our backend.

I cannot find that issue atm.

[henryharbeck]

I cannot find that issue atm.

I think this is it here

[deanm0000]

@orlp I don't think it's a question of preference. Modulo division is well established so if a programming language or library says it's doing modulo division then the result should be the same or else it's doing the wrong thing.

@ritchie46 In the other issue, the confusion was strictly about the % operator. Rust defines the % operator as remainder division whereas python defines % as modulo division. That's just a question of convention as there's nothing in math that says what % should mean. That's an open point of confusion but I don't think there's an inherently right or wrong decision.

By contrast rust has mod too.

If I'm not mistaken, the current situation is that polars's mod uses rust's % instead of rust's mod.

[orlp]

By contrast rust has mod too.

@deanm0000 Euclidean division/modulo in Rust is still wrong for negative divisors.

I don't think it's a question of preference. Modulo division is well established so if a programming language or library says it's doing modulo division then the result should be the same or else it's doing the wrong thing.

Unfortunately, that's not the case. There are many variants all referred to as 'modulo': https://en.wikipedia.org/wiki/Modulo

Again, I would strongly prefer Python's definition because I think it's the most mathematically elegant. But it's not (sadly) universal.

[eitsupi]

However this also means we must update integer division to be consistent with it. The identity (a / b) * b + (a % b) == a must always hold.

If I am correct, I don't think floor_div (floordiv) and rem (mod) in polars currently satisfy this.
Wouldn't this be grounds for changing the behavior of the mod?

>>> x = -1
>>> y = 3
>>> x == (x % y) + y * (x // y)
True
>>> import polars as pl
>>> x_pl = pl.lit(x)
>>> y_pl = pl.lit(y)
>>> pl.select(x_pl == (x_pl % y_pl) + y_pl * (x_pl // y_pl))
shape: (1, 1)
┌─────────┐
│ literal │
│ ---     │
│ bool    │
╞═════════╡
│ false   │
└─────────┘
>>> pl.select(x == (x % y) + y * (x // y))
shape: (1, 1)
┌─────────┐
│ literal │
│ ---     │
│ bool    │
╞═════════╡
│ true    │
└─────────┘

[samedii]

Current behaviour is very unexpected for a python math lib. It felt like debugging if something as simple as addition is working as expected.

[eitsupi]

However this also means we must update integer division to be consistent with it. The identity (a / b) * b + (a % b) == a must always hold.

If I am correct, I don't think floor_div (floordiv) and rem (mod) in polars currently satisfy this. Wouldn't this be grounds for changing the behavior of the mod?

>>> x = -1
>>> y = 3
>>> x == (x % y) + y * (x // y)
True
>>> import polars as pl
>>> x_pl = pl.lit(x)
>>> y_pl = pl.lit(y)
>>> pl.select(x_pl == (x_pl % y_pl) + y_pl * (x_pl // y_pl))
shape: (1, 1)
┌─────────┐
│ literal │
│ ---     │
│ bool    │
╞═════════╡
│ false   │
└─────────┘
>>> pl.select(x == (x % y) + y * (x // y))
shape: (1, 1)
┌─────────┐
│ literal │
│ ---     │
│ bool    │
╞═════════╡
│ true    │
└─────────┘

This does not seem to have been fixed yet.