3 ms·

So when Rust implemented this they chose to leave the % operator like in C and hide the one that is more useful for humans behind `rem_euclid`. This is unfortu

So when Rust implemented this they chose to leave the % operator like in C and hide the one that is more useful for humans behind `rem_euclid`. This is unfortunate but at least it exists. The RFC that introduced rem_euclid: https://github.com/rust-lang/rfcs/blob/master/text/2169-euclidean-modulo.md https://github.com/rust-lang/rfcs/blob/master/text/2169-eucl...

masklinn 5y ago
> So when Rust implemented this For what it's worth, Python does not implement euclidean modulo (it implements flooring division aka "F-definition", proposed by Knuth), so Rust did not implement "this" it implemented an operation which, as far as I can tell, Python doesn't have.
- the_mitsuhiko 5y ago
  The difference between flooring and euclidean modulo is quite irrelevant in practice for the most part. Either way resolve the main issue with truncating modulo that is the issue outlined in the tweet.
  - masklinn 5y ago
    > The difference between flooring and euclidean modulo is quite irrelevant in practice for the most part. It seems quite relevant as it diverges significantly from the assertion put forth in the tweet: Python's remainder takes the sign of the divisor. So flooring division fixes the more common issue but leaves an other one present.
    - the_mitsuhiko 5y ago
      The tweet we're discussing: > python, unlike C, had the mod operator always return a positive number, even if the first argument is negative That is true for Rust's rem_euclid as well: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=59080e23e6c7dcf60e5ef766b52e1d20 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - housecarpenter 5y ago
      In practice, when you use a modulo operator the second operand is usually some kind of length or size, which is inherently non-negative, while the first operand is an index or offset, which could easily be negative if there's no natural origin point. So it's much rarer that you have to deal with a potentially negative second operand, compared to having to deal with a potentially negative first operand.

masklinn 5y ago

> So when Rust implemented this For what it's worth, Python does not implement euclidean modulo (it implements flooring division aka "F-definition", proposed by Knuth), so Rust did not implement "this" it implemented an operation which, as far as I can tell, Python doesn't have.

the_mitsuhiko 5y ago
The difference between flooring and euclidean modulo is quite irrelevant in practice for the most part. Either way resolve the main issue with truncating modulo that is the issue outlined in the tweet.
- masklinn 5y ago
  > The difference between flooring and euclidean modulo is quite irrelevant in practice for the most part. It seems quite relevant as it diverges significantly from the assertion put forth in the tweet: Python's remainder takes the sign of the divisor. So flooring division fixes the more common issue but leaves an other one present.
  - the_mitsuhiko 5y ago
    The tweet we're discussing: > python, unlike C, had the mod operator always return a positive number, even if the first argument is negative That is true for Rust's rem_euclid as well: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=59080e23e6c7dcf60e5ef766b52e1d20 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - housecarpenter 5y ago
    In practice, when you use a modulo operator the second operand is usually some kind of length or size, which is inherently non-negative, while the first operand is an index or offset, which could easily be negative if there's no natural origin point. So it's much rarer that you have to deal with a potentially negative second operand, compared to having to deal with a potentially negative first operand.