(Mathematical) modulo operator

[ExpHP]

@varkor

Unless there’s a good reason not to, I would lean towards flooring modulo which has the advantages that: (a) it requires one fewer (abs) operations; (b) can easily be used to implement Euclidean modulo if really needed.

I don't buy these arguments as they can be easily turned around depending on how they are implemented. One could say euclidean division uses two fewer sign comparisons (compare modE and modF on page 5). One would have to benchmark various implementations of both algorithms to find the global minimum.

[fanzier]

Thanks for writing this up!

Ad 1: I don’t think it’s useful to have both flooring and Euclidean division available as functions, at least not in this verbose form. Who wants to write 5.mod_round(3, num::DivisionMode::Euclidean) instead of, say, 5.mod_e(3)? I think short names are important here given that the worst choice (truncating mod) is one character %.

Ad 2: So a single division/modulo function is definitely better. I have a slight preference for Euclidean division (it’s more well-behaved according to the paper linked in your first post) but if flooring division is faster, then I’m fine with sacrificing the regularity of Euclidean division for the performance of flooring division. But I agree with @ExpHP that there seems to be no evidence so far supporting the statement that flooring division is faster.

Small proposal: I also think it might be useful to add a fn divMod(self, rhs: Self) -> (Self, Self) function, returning the division and modulo result, similarly to Haskell. Such a function could also be added later, of course, if you want to keep the RFC minimal.

[varkor]

@ExpHP

One would have to benchmark various implementations of both algorithms to find the global minimum.

You're right; I should have benchmarked first: using the algorithms in the paper gives functions with essentially identical performance (for all three rounding variants, and for both division and modulo).

@fanzier

Small proposal: I also think it might be useful to add a fn divMod(self, rhs: Self) -> (Self, Self) function, returning the division and modulo result, similarly to Haskell.

I think it would be better to address this in a future proposal, as it does not appear strictly related to the issue this RFC focuses on.

The preference expressed at least here seems to be for Euclidean modulo, so I'll focus on that in the RFC (hopefully to follow shortly). Thanks for all your feedback so far!

[scottmcm]

The biggest opposition I expect to the RFC is why it needs to be in core. The standard library’s support for mathy stuff in general is poor, mostly on purpose. So this will need a clear benefit to being in core instead of, say, the num crate.

[leonardo]

@scottmcm

So this will need a clear benefit to being in core instead of, say, the num crate.

In my opinion the main benefit of having this in the Prelude or std library is to help new programmers be aware of the pitfalls of the built-in operators.

[cuviper]

@scottmcm

So this will need a clear benefit to being in core instead of, say, the num crate.

Integer already provides flooring methods. I expect it would be simple to add Euclidean methods too, if someone would like to send a PR.

[scottmcm]

With the div_rem and div_mod_floor functions too!

[varkor]

You can now find the RFC here! Thank you for all your constructive comments beforehand — there are probably still details to work out, but the ideas feel a lot stronger now.

@cuviper

I expect it would be simple to add Euclidean methods too, if someone would like to send a PR.

That could be a good stop-gap! I do think it is useful enough to warrant a core implementation, but as an RFC can take a while to progress, a num PR could be a way to provide the functionality earlier.

[varkor]

As a final follow up to the discussion here, (unstable) Euclidean modulo methods have now been added to the standard library: thanks @fanzier for implementing the RFC!