是否有任何文件说明了.NET BigIntegers的确切数字范围?


12

我正在使用.NET BigInteger,基本上我想知道是什么数字(估计的答案会很好) 是((操作所需时间增加的图表)vs (BigInteger的值)?

还是它们的设计没有这样的偏差,如果我们将操作所需的时间与BigInteger的值之间的增量从1绘制到无穷大,我们将一直保持平滑的曲线吗?

例如,假设数组被设计为可以处理50个项目。这意味着如果我有1个项目,则运算是f(1)时间。当我有2个项目时,运算时间为f(2)。如果我有50个项目,则操作时间为f(50)。但由于它仅设计用于处理50个项目,因此当我们拥有51个项目时,所执行的操作将为g(51),其中g(51)> f(51)。

如果实施正确,BigInteger算法的复杂度应为平滑曲线。例如,乘法的时间复杂度应为O(NM),其中N是第一个被乘数的位数,而M是第二个被乘数的位数。当然,有实际的限制,因为您可以选择N和M太大,以至于这些数字都不适合您的计算机。

是否有/任何人知道任何声称已如此实施的文件?


3
@不赞成投票的人,如果不能发表评论解释为什么这个问题不是一个好问题,不赞成票毫无意义。我对此表示赞同,因为我认为它没有问题。
松饼人

我没有投票,但是我不确定这里是什么问题。您是否想知道bigints上的操作的运行时/内存复杂性(加法,乘法,除法等)?
nikie 2011年

例如,假设数组被设计为可以处理50个项目。这意味着如果我有1个项目,并且运算是f(1)时间。当我有2个项目时,运算时间为f(2)。如果我有50个项目,操作时间为f(50)。但由于它仅设计用于处理50件物品,因此当我们拥有51件物品时完成的操作将为g(51),其中g(51)> f(51)
Pacerier,2011年

@查尔斯E.格兰特是的!这就是我在说的。问题是/是否有人知道有任何声称是照此实施的文件?
Pacerier,2011年

@Paceier我已将评论移至我的答案,并添加了指向讨论此问题的文档的链接。
查尔斯E.格兰特

Answers:


7

任何可能大于ULong.MaxValue或小于Long.MinValue的数字都应使用BigInteger表示。

如果不是(Long.MinValue <= X <= ULong.MaxValue),则BigInteger

BigInteger的数字太大,无法正常处理的原始数据。

例如,如果您的整数超出Long范围,则您可能应该使用BigInteger。但是,这些情况很少见,并且使用这些类的开销比其原始对应类高得多。

例如,它long是64位宽,可以容纳的范围为:-9,223,372,036,854,775,808至9,223,372,036,854,775,80。ulong可以容纳0到18,446,744,073,709,551,615。如果您的数字大于或小于该数字,则BigInteger是您的唯一选择

我看到它们在实际应用中使用的唯一一次是淀粉喷枪应用。

另请参见:.NET中的原始范围


我的意思是我当然知道只要有可能就应该使用普通的原语..我的意思是说BigInteger是为大于ULong.MaxValue的数字设计100倍的数字还是BigInteger是为大于ULong.MaxValue的数字100k的数字设计的?我的意思是我知道它可以支持比ULong.MaxValue大100k倍的问题,但是它是在考虑此范围的情况下设计的,还是在声明为“非常规要求”的范围内进行设计的?
Pacerier,2011年

5
如果不使用BigInteger,则不能表示比ULong.MaxValue大一的数字。任何可能大于ULong.MaxValue的数字都应为BigInteger。
Malfist 2011年

当然,有一些方法可以表示大于ULong.MaxValue的数字,而无需使用BigInteger。我可以简单地编写一个包含ULong和布尔值和中提琴的自定义结构,我最多可以代表ULong的两倍。MaxValue–
Pacerier

是的,但是使用BigInteger并不那么复杂,并且可能不会更快,甚至更快,并且不会像BigInteger那样灵活。您也可以用布尔数组表示非常大的数字,但这太复杂了。
Malfist 2011年

2
@Mavrik,他已将其更改为与我回答的问题完全不同的问题。
Malfist 2011年

4

从某种意义上说,BigInteger的意义不是绝对大小,而是无限精度。浮点数也可能非常大,但精度有限。BigInteger使您无需担心舍入错误或溢出就可以进行算术运算。您要付出的代价是它比普通整数或浮点数算术要慢数百倍。

正如其他人指出的,ulong可以保持0到18,446,744,073,709,551,615之间,并且只要您保持在该范围内,就可以执行精确的算术运算。如果超出该范围甚至达到1,就会溢出,因此如果需要精确的算术,则问题的答案是使用BigInteger,并且任何中间结果都可能超过18,446,744,073,709,551,615。

科学,工程和金融领域的大多数问题都可以忍受浮点数逼近的逼近,并且无法承受BigInteger算术的时间成本。大多数商业计算不能使用浮点算法的近似值,但是可以在0到18,446,744,073,709,551,615的范围内工作,因此可以使用普通的算术。当使用数字理论的算法(包括密码学(认为50位素数))时,需要使用BigInteger。当需要精确计算,速度不太重要并且建立适当的固定小数点系统太麻烦时,有时也可以在商业应用中使用它。

如果实施正确,BigInteger算法的复杂度应为平滑曲线。例如,乘法的时间复杂度应为O(NM),其中N是第一个被乘数的位数,而M是第二个被乘数的位数。当然,有实际的限制,因为您可以选择N和M太大,以至于这些数字都不适合您的计算机。

如果您使用“ biginteger的计算复杂性”进行搜索,那么您将获得更多的参考资料,而不可动摇。直接说明您问题的一个是:两个任意精度算术包的比较


4

内存限制

BigInteger依赖于int数组进行存储。假设这样做,BigInteger可以表示的最大数量的理论限制可以从.net中可用的最大数组大小中得出。这里有一个关于数组的SO主题:查找可以为C#中的数组分配多少内存

假设我们知道最大数组大小,那么我们可以估计BigInteger可以表示的最大数目:(2 ^ 32)^ max_array_size,其中:

  • 2 ^ 32-数组单元中的最大数目(int)
  • max_array_size-整数数组的最大允许大小,该大小受2GB对象大小的限制

这使数字具有6亿个十进制数字。

性能极限

在性能方面,BigInteger使用Karatsuba算法进行乘法运算,并使用线性算法进行加法运算。乘法的复杂度为3 * n ^ 1.585,这意味着即使对于较大的数,它也可以很好地扩展(“ 复杂度”图),但是根据RAM和处理器缓存的大小,您仍然可能会遭受性能损失。

到目前为止,由于最大数字大小限制为2GB,在下降的计算机上,您不会看到意想不到的性能差距,但是仍然在6亿个数字上运行将非常缓慢。


这是很棒的信息,但是BigInteger依赖于int数组的源在哪里?
Pacerier,2011年

我只是使用dotPeek挖掘了.net源代码。似乎数字本身存储在BigInteger结构的uint [] _data内部。
Valera Kolupaev 2011年

*更新了更详细的答案,但是,除了反编译的代码片段之外,我找不到任何我可以引用的.net源代码。
Valera Kolupaev 2011年

在我看来,.NET中存在一种标准的乘法算法,可以从ILSpy中找到它:.NET BigInteger乘法
Ivan Kochurkin 2014年

1

限制是您的内存大小(以及您的时间)。因此,您可以拥有很大的数字。正如凯文所说,在密码学中,数字必须与几千个(二进制)数字相乘或取幂,这是可能的,没有任何问题。

当然,随着数字的增加,算法通常会变慢,但不会变慢。

但是,当您使用兆位范围内的数字时,您可能需要考虑其他解决方案-因为使用它们进行真正的计算也会变慢。


0

科学界内部有一些用途(例如,星系之间的距离,草丛中的原子数等)。


嗯,不要无礼..但是这个答案与问题有什么关系?
Pacerier,2011年

2
从书面上看,这个问题听起来像是他在寻找为什么需要创建此类数据类型的真实示例。
戴夫·怀斯

更好的改写是“ BigInteger真的适合于10 ^ 30的数字”吗?
Pacerier,2011年

为此,我会更好地利用doublefloat-你没有必要的精度反正。
圣保罗Ebermann

更好的改写是“当我们需要精度时,BigInteger是否真的适合于10 ^ 30的数字”?
Pacerier,2011年

0

正如kevin cline的答案所暗示的那样,BigNumber主要是被添加到.NET库中,因为它们是许多现代密码算法(数字签名,公共/私有密钥加密等)的基础。许多现代密码算法都涉及对大小最大为几千位的整数值的计算。由于BigNumber类描述了一个定义良好且有用的类,因此他们决定将其公开(而不是将其保留为加密API的内部细节)。


顺便说一句,您只是想知道将BigNumbers添加到.NET库的源头在哪里,主要是因为它们是许多现代密码算法的构建块(因此应该能够支持高达数千位的值)?
Pacerier,2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.