大数类型
我正在开发一个需要处理大量数字的应用程序。
我检查了一些可用的 LargeNumber 类，并发现了一些我满意的类。 我有一个用于大整数和大浮点数的类。
由于有些数字很小，有些很大，所以问题是是否值得检查数字的长度，如果数字很小，则使用常规 C# int 或 double，如果很大，则使用我拥有的其他类，或者如果我我已经在使用 Large Integer 和 Large Float 类，即使对于较小的数字，我也应该坚持使用它们。
我的考虑纯粹是性能。 我是否可以节省足够的时间来计算较小的数字，以便在输入后检查每个数字是值得的。
I am working on an app that will need to handle very large numbers.
I checked out a few available LargeNumber classes and have found a few that I am happy with. I have a class for large integers and for large floating point numbers.
Since some of the numbers will be small and some large the question is whether it is worth checking the length of the number and if it is small use a regular C# int or double and if is is large use the other classes I have or if I am already using the Large Integer and Large Float classes I should just stick with them even for smaller numbers.
My consideration is purely performance. Will I save enough time on the math for the smaller numbers that it would be worthwhile to check each number after is is put in.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
真的很难说 - 取决于您的第 3 方库:)
最好的选择是使用 System.Diagnostics.StopWatch 类，进行大量不同的计算，对它们进行计时并比较结果，我猜..
[编辑] - 关于基准测试，我会对你的 largeInt 类型进行一系列基准测试，以对常规 32/64 位数字进行计算，并进行一系列检查该数字是否适合常规 Int32/Int64 类型（它们应该），“向下转型" 将它们转换为这些类型，然后使用这些类型运行相同的计算。 从你的问题来看，这听起来像是如果内置类型更快的话你会做什么。
如果你的应用程序的目标用户比你自己多，请尝试在不同的机器上运行它们（单核、多核、32 位、64 位）平台），如果平台似乎对计算时间有很大影响，请使用某种策略模式在不同的机器上以不同的方式进行计算。
祝你好运 ：）
Really hard to tell - Depends on your 3rd party libraries :)
Best bet would be to use the System.Diagnostics.StopWatch class, do a gazzillion different calculations, time them and compare the results, I guess ..
[EDIT] - About the benchmarks, I'd do a series of benchmarks your largeInt-type to do the calculations on regular 32/64 bits numbers, and a series checking if the number can fit in the regular Int32/Int64 types (which they should), "downcasting" them to these types, and then run the same calculations using these types. From your question, this sounds like what you'll be doing if the built-in types are faster..
If your application is targetted for more people than yourself, try to run them on different machines (single core, multicore, 32bit, 64bit platforms), and if the platform seems to have a large impact in the time the calculations take, use some sort of strategy-pattern to do the calculations differently on different machines.
Good luck :)
我希望一个像样的大数库能够自己进行这种优化......
I would expect that a decent large numbers library would be able to do this optimization on it's own...
我想说是的，只要您在正常范围内有足够的价值，这张支票就足以物有所值。
逻辑很简单：整数加法是一条汇编指令。 结合比较，那就是三到四个指令。 此类操作的任何软件实现很可能会慢得多。
最佳情况下，此检查应在 LargeNumber 库本身中完成。 如果他们不这样做，您可能需要一个包装纸以避免到处检查。 但随后您还需要考虑包装纸的额外成本。
I would say yes, the check will more than pay for itself, as long as you have enough values within the regular range.
The logic is simple: an integer addition is one assembly instruction. Combined with a comparison, that's three or four instructions. Any software implementation of such operation will most probably be much slower.
Optimally, this check should be done in the LargeNumber libraries themselves. If they don't do it, you may need a wrapper to avoid having checks all over the place. But then you need to think of the additional cost of the wrapper as well.
在一个项目中工作，其中相同的字段需要处理非常大的数字，同时需要处理非常小的数字的精度。
最终将每个此类数字存储到字段（尾数和指数）。
我们制作了一个用于尾数/指数计算的类，并且表现良好。
Worked in a project where the same fields needed to handle very large numbers and at the same time handels precision for very small numbers.
The ended up with storing to fields (mantissa and exponent) for every number of such kind.
We made a class for mantissa/exponent calculations and it performed well.