gmp - 为什么 BigFloat.to_s 不够精确？

Question

我不确定这是否是一个错误。但是我一直在玩big我不明白为什么这段代码会这样工作:
https://carc.in/#/r/2w96
代码

require "big"

x = BigInt.new(1<<30) * (1<<30) * (1<<30)
puts "BigInt: #{x}"

x = BigFloat.new(1<<30) * (1<<30) * (1<<30) 
puts "BigFloat: #{x}"
puts "BigInt from BigFloat: #{x.to_big_i}"

输出

BigInt: 1237940039285380274899124224
BigFloat: 1237940039285380274900000000
BigInt from BigFloat: 1237940039285380274899124224

首先，我认为 BigFloat 需要更改 BigFloat.default_precision与更大的数字一起工作。但从这段代码看来，它似乎只在尝试输出 #to_s 时才重要。值(value)。
与设置为 1024 ( https://carc.in/#/r/2w98 ) 的 BigFloat 精度相同:
输出

BigInt: 1237940039285380274899124224
BigFloat: 1237940039285380274899124224
BigInt from BigFloat: 1237940039285380274899124224

BigFloat.to_s使用 LibGMP.mpf_get_str(nil, out expptr, 10, 0, self) . GMP在哪里说:

mpf_get_str (char *str, mp_exp_t *expptr, int base, size_t n_digits, const mpf_t op)

Convert op to a string of digits in base base. The base argument may vary from 2 to 62 or from -2 to -36. Up to n_digits digits will be generated. Trailing zeros are not returned. No more digits than can be accurately represented by op are ever generated. If n_digits is 0 then that accurate maximum number of digits are generated.

谢谢。

Answer 1

在 GMP 中(它适用于所有语言，而不仅仅是 Crystal)，整数(C mpz_t，Crystal BigInt)和浮点数(C mpf_t，Crystal BigFloat)具有单独的默认精度。

另外，请注意使用显式精度比设置默认精度更好，因为默认精度可能不是可重入的(它取决于 configure -time 开关)。此外，如果有人只阅读了您的代码的一部分，他们可能会跳过设置默认精度的部分并假设错误。尽管我不太了解 Crystal 绑定(bind)，但我认为此类功能在某处公开。

零参数传递给 mpf_get_str意思是根据精度来猜测值。我知道有效数字的数量是成比例的并且接近 precision / log2(10) .浮点数具有有限的精度。在那种情况下，它不是 mpf_get_str使最后一位数字为零的调用-内部表示没有保留此类数据。看起来您的(默认)精度太小而无法存储所有必要的数字。

总结一下，有两种解决方案:

设置全局默认精度。 尽管这种方法可行，但它需要经常更改默认精度，或者在整个程序中使用一个。两种方式，默认精度的方法都是拖延的一种形式，以后会报仇。

在变量的基础上设置精度。 这是比前者更好的解决方案。虽然它需要更多的代码(每个变量初始化多 1-2 行)，但它会在以后得到返回。例如，在空间物体跟踪系统中，物理计算必须非常精确，但其他系统可以使用较低精度的数字来提高速度和节省内存。

我仍然不确定是什么导致了转换 BigFloat --> BigInt产生缺失的数字。