使 Java 的模数表现得像负数那样的最佳方法？
在java中，当你这样做时
a % b
，如果a为负数，它将返回负结果，而不是像它应该的那样绕回b。解决这个问题的最佳方法是什么？我能想到的唯一办法就是
a < 0 ? b + a : a % b
In java when you do
a % b
If a is negative, it will return a negative result, instead of wrapping around to b like it should. What's the best way to fix this? Only way I can think is
a < 0 ? b + a : a % b
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
它的行为应该是：
a % b = a - a / b * b;即它是余数。您可以执行
(a % b + b) % b。该表达式的工作原理是，无论
a是正数还是负数，(a % b)的结果都必然低于b。添加b可以处理a的负值，因为(a % b)是-b之间的负值code> 和0，(a % b + b)必然低于b并且为正值。最后一个模是在a开始时为正数的情况下出现的，因为如果a为正数(a % b + b)会变得更大比b。因此，(a % b + b) % b再次将其变为小于b（并且不会影响负的a值）。It behaves as it should:
a % b = a - a / b * b; i.e. it's the remainder.You can do
(a % b + b) % b.This expression works as the result of
(a % b)is necessarily lower thanb, no matter ifais positive or negative. Addingbtakes care of the negative values ofa, since(a % b)is a negative value between-band0,(a % b + b)is necessarily lower thanband positive. The last modulo is there in caseawas positive to begin with, since ifais positive(a % b + b)would become larger thanb. Therefore,(a % b + b) % bturns it into smaller thanbagain (and doesn't affect negativeavalues).从 Java 8 开始，您可以使用 Math.floorMod (int x, int y) 和 Math.floorMod(长 x, 长 y)。这两种方法都返回与 Peter 的答案相同的结果。
As of Java 8, you can use Math.floorMod(int x, int y) and Math.floorMod(long x, long y). Both of these methods return the same results as Peter's answer.
对于那些尚未使用（或无法使用）Java 8 的人，Guava 可以通过 IntMath.mod()，自 Guava 11.0 起可用。
需要注意的是：与 Java 8 的 Math.floorMod() 不同，除数（第二个参数）不能为负数。
For those not using (or not able to use) Java 8 yet, Guava came to the rescue with IntMath.mod(), available since Guava 11.0.
One caveat: unlike Java 8's Math.floorMod(), the divisor (the second parameter) cannot be negative.
在数论中，结果总是正的。我猜想在计算机语言中情况并非总是如此，因为并非所有程序员都是数学家。我的两分钱，我认为这是语言的设计缺陷，但你现在无法改变它。
=MOD(-4,180) = 176
=MOD(176, 180) = 176
因为 180 * (-1) + 176 = -4 与 180 * 0 + 176 = 176 相同
使用此处的时钟示例，http://mathworld.wolfram.com/Congruence.html
你不会说duration_of_time mod period_length是-45分钟，你会说15分钟，即使两个答案都满足基本方程。
In number theory, the result is always positive. I would guess that this is not always the case in computer languages because not all programmers are mathematicians. My two cents, I would consider it a design defect of the language, but you can't change it now.
=MOD(-4,180) = 176
=MOD(176, 180) = 176
because 180 * (-1) + 176 = -4 the same as 180 * 0 + 176 = 176
Using the clock example here, http://mathworld.wolfram.com/Congruence.html
you would not say duration_of_time mod cycle_length is -45 minutes, you would say 15 minutes, even though both answers satisfy the base equation.
Java 8 有 Math.floorMod，但它非常慢（它的实现有多个除法、乘法和一个条件）。然而，JVM 可能有一个内在优化的存根，这会显着加快速度。
没有
floorMod实现这一点的最快方法就像这里的其他一些答案一样，但没有条件分支，只有一个缓慢的%操作。假设 n 是正数，x 可以是任何值：
n = 3时的结果：如果您只需要
0和n-1之间均匀分布code> 而不是确切的 mod 运算符，并且您的x不会聚集在0附近，下面的代码会更快，因为有更多的指令级并行性并且缓慢的%计算将与其他部分并行发生，因为它们不依赖于其结果。return ((x >> 31) & (n - 1)) + (x % n)对于上述
n = 3的结果：如果输入在 int 的整个范围内是随机的，两个解的分布将是相同的。如果输入簇接近于零，则后一个解决方案中
n - 1处的结果将会太少。Java 8 has
Math.floorMod, but it is very slow (its implementation has multiple divisions, multiplications, and a conditional). Its possible that the JVM has an intrinsic optimized stub for it, however, which would speed it up significantly.The fastest way to do this without
floorModis like some other answers here, but with no conditional branches and only one slow%op.Assuming n is positive, and x may be anything:
The results when
n = 3:If you only need a uniform distribution between
0andn-1and not the exact mod operator, and yourx's do not cluster near0, the following will be even faster, as there is more instruction level parallelism and the slow%computation will occur in parallel with the other parts as they do not depend on its result.return ((x >> 31) & (n - 1)) + (x % n)The results for the above with
n = 3:If the input is random in the full range of an int, the distribution of both two solutions will be the same. If the input clusters near zero, there will be too few results at
n - 1in the latter solution.这是一个替代方案：
这可能会或可能不会比其他公式 [(a % b + b) % b] 更快。与其他公式不同，它包含一个分支，但使用较少的模运算。如果计算机能够预测 <<，则可能是胜利。 0 正确。
（编辑：修正了公式。）
Here is an alternative:
This might or might not be faster than that other formula [(a % b + b) % b]. Unlike the other formula, it contains a branch, but uses one less modulo operation. Probably a win if the computer can predict a < 0 correctly.
(Edit: Fixed the formula.)
FloorMod 方法是最好的方法。
我很惊讶没有人发布明显的信息。
The floorMod method is the best way to go.
I am surprised no one posted the obvious.