Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

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-eucl...

View on HN

> 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 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.

> 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 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&editio...

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.

Reply on news.ycombinator.com