blocks|key|986377|text|Math.Pow(142,+23)太大了，无法精确地用双人表示。所以你的模数是在有耗的计算上做的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|986378|这将给出正确的答案：|986379|BigInteger.ModPow(142,+23,+187);|code-block|syntax|javascript|986380|BigInteger可以在System.Numerics命名空间和程序集中找到。|986381|如果您想要的话，您也可以自己高效地实现这一点，对于您在问题中使用的大小的整数来说。|986382|private+static+int+ModPow(int+basenum,+int+exponent,+int+modulus)
{
++++if+(modulus+==+1)
++++{
++++++++return+0;
++++}
++++int+result+=+1;
++++for+(var+i+=+0;+i+<+exponent;+i%2B%2B)
++++{
++++++++result+=+(result+*+basenum)+%25+modulus;
++++}
++++return+result;
}|986383|BigInteger用二进制指数做了一些更聪明的事情，这将对真正庞大的数字更好地工作。|986384|entityMap^0|0|H|0|0|0|0|A|D|F|0|0|0|0|A|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|10|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|16|8|@]|D|@]|E|$]]|$1|Q|3|R|5|J|7|17|8|@]|D|@]|E|$K|L]]|$1|S|3|T|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]]|V|$]]

<code>Math.Pow(142, 23)</code> is too big to accurately be represented by a double. So your modulus is done on a lossy calculation.

This will give the correct answer:

<pre><code>BigInteger.ModPow(142, 23, 187);
</code></pre>

<code>BigInteger</code> can be found in the <code>System.Numerics</code> namespace and assembly.

You can also implement this yourself efficiently if you want like so for integers of the size you were using in your question.

<pre><code>private static int ModPow(int basenum, int exponent, int modulus)
{
 if (modulus == 1)
 {
 return 0;
 }
 int result = 1;
 for (var i = 0; i &lt; exponent; i++)
 {
 result = (result * basenum) % modulus;
 }
 return result;
}
</code></pre>

<code>BigInteger</code> does something more clever with binary exponentiation which will work better with truly huge number.

blocks|key|2924777|text|如果我们使用BigInteger来计算指数的全部结果：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2924778|var+bi+=+BigInteger.Pow(142,+23);
Debug.WriteLine(bi);|code-block|syntax|javascript|2924779|我们得到了一个非常大的数字：|2924780|31814999504641997296916177121902819369397243609088
or
3.1814999504642E%2B49|2924781|如果我们然后将该值转换为double，则会导致精度下降，然后返回到BigInteger|2924782|var+d+=+(double)+bi;
bi+=+new+BigInteger(d);
Debug.WriteLine(bi);|2924783|我们得到：|2924784|31814999504641997296916177121902819369397243609088++--+BigInteger
31814999504641993108158684988768059669621048868864++--+BigInteger+->+double+->+BigInteger
++++++++++++++++%5E+oh+no+mah+precision|2924785|在十六进制中，精度损失更为明显：|2924786|15C4+C9EB+18CD+25CE+858D+6C2D+C3E5+D319+BC9B+8000+00
15C4+C9EB+18CD+2500+0000+0000+0000+0000+0000+0000+00+++
+++++++++++++++++%5E+oh+no+mah+precision|2924787|您会注意到，精度损失发生在十七个小数位，或者十四个十六进制数字。|2924788|为什么？|2924789|+is+stored+using+IEEE-754+encoding|2924790|Significand+or+mantissa:++++++++++0-51
Exponent:+++++++++++++++++++++++++52-62
Sign+(0+=+Positive,+1+=+Negative)+63|2924791|这里的关键是尾数的52位。我们的14位十六进制数字是56位，接近52位限制.我们怎么解释这个4位差异呢？|2924792|(我想我在下面的解释中犯了一个错误。如果有人能指出，我将不胜感激)|2924793|最后一个不变的十六进制数字是C，或二进制的1100；因为最后两个位是零，所以我们的数字是用54位编码的，而不是56位。所以，这实际上是一个2位的差异。|2924794|我们如何解释最后两部分呢？这是由于如何确定IEEE-754的分数分量。我已经很久没有这样做了，所以我将把它作为一个练习留给读者：|2924795|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Double-precision_floating-point_format^0|6|A|0|0|0|0|X|A|0|0|0|0|0|0|0|0|0|Y|0|0|0|0|0|E|1|L|4|0|0^^$0|@$1|2|3|4|5|6|7|1O|8|@$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|1R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1S|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|1T|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|H|7|1X|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|1Y|8|@]|D|@]|E|$]]|$1|U|3|V|5|H|7|1Z|8|@]|D|@]|E|$I|J]]|$1|W|3|X|5|6|7|20|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|H|7|21|8|@]|D|@]|E|$I|J]]|$1|10|3|11|5|6|7|22|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|23|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|24|8|@]|D|@$9|25|A|26|1|27]]|E|$]]|$1|16|3|17|5|H|7|28|8|@]|D|@]|E|$I|J]]|$1|18|3|19|5|6|7|29|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|6|7|2A|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|6|7|2B|8|@$9|2C|A|2D|B|C]|$9|2E|A|2F|B|C]]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|2G|8|@]|D|@]|E|$]]|$1|1G|3|-4|5|6|7|2H|8|@]|D|@]|E|$]]]|1H|$1I|$5|1J|1K|1L|E|$1M|1N]]]]

If we use <code>BigInteger</code> to compute the full result of the exponential:

<pre><code>var bi = BigInteger.Pow(142, 23);
Debug.WriteLine(bi);
</code></pre>

We get this very large number:

<pre><code>31814999504641997296916177121902819369397243609088
or
3.1814999504642E+49
</code></pre>

If we then convert that value to a double, to cause a loss of precision, and then back to a <code>BigInteger</code>:

<pre><code>var d = (double) bi;
bi = new BigInteger(d);
Debug.WriteLine(bi);
</code></pre>

We get:

<pre><code>31814999504641997296916177121902819369397243609088 -- BigInteger
31814999504641993108158684988768059669621048868864 -- BigInteger -&gt; double -&gt; BigInteger
 ^ oh no mah precision
</code></pre>

In hexadecimal, where the loss of precision is more obvious:

<pre><code>15C4 C9EB 18CD 25CE 858D 6C2D C3E5 D319 BC9B 8000 00
15C4 C9EB 18CD 2500 0000 0000 0000 0000 0000 0000 00 
 ^ oh no mah precision
</code></pre>

You'll notice that the loss of precision occurs at the 17th decimal digit, or the 14th hexadecimal digit. 

Why?

<a href="https://en.wikipedia.org/wiki/Double-precision_floating-point_format" rel="nofollow noreferrer">A <code>double</code> is stored using IEEE-754 encoding</a>:

<pre><code>Significand or mantissa: 0-51
Exponent: 52-62
Sign (0 = Positive, 1 = Negative) 63
</code></pre>

The key here is 52 bits for the mantissa. Our 14 hexadecimal digits are 56 bits, close to the 52-bit limit. How can we account for the 4-bit discrepancy?

(I think I made a mistake in the explanation that follows. If someone can point it out, I would be grateful)

The last unchanged hex digit is <code>C</code>, or <code>1100</code> in binary; since the last two bits are zeroes, our number was encoded in 54 bits, not 56. So, it's actually a 2-bit discrepancy.

How do we account for the last two bits? This is due to how the fractional component of IEEE-754 is determined. It's been a long time since I did this, so I'll leave it as an exercise for the reader :)

So I wanted to write this method : 142^23 (mod 187), and using any calculator I get the result 65 but with this piece of code : 
<code>double number = Math.Pow(142, 23) % 187</code>
I get a result of 53. Why is this, and what am I doing wrong here?

C#, Modulo operation gives diffrent result than a calculator

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

所以我想写一个方法: 142^23 (mod 187)，使用任何计算器我得到结果65，但是用这段代码：double number = Math.Pow(142, 23) % 187我得到了53的结果。为什么，我在这里做错什么了？

问C#，Modulo运算给出了与计算器不同的结果
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#，Modulo运算给出了与计算器不同的结果EN