为啥增加小数位数不影响欧几里得距离的计算时间?
Posted
技术标签:
【中文标题】为啥增加小数位数不影响欧几里得距离的计算时间?【英文标题】:Why does increasing the number of decimal places not affect the computation time of Euclidean distance?为什么增加小数位数不影响欧几里得距离的计算时间? 【发布时间】:2021-05-19 05:08:58 【问题描述】:我正在尝试对 KMeans 程序进行微基准测试。我现在专注于欧几里得距离。我认为(由于平方根,下面)增加每个坐标 (x, y) 的小数位数会导致计算时间增加。
这是我计算欧几里得距离的方法:
Math.sqrt((x - otherPoint.x) * (x - otherPoint.x) + (y - otherPoint.y) * (y - otherPoint.y))
这是我的微基准测试结果:
Benchmark (noOfFloatingPoints) (noOfPoints) Mode Cnt Score Error Units
TheBenchmark.toyBenchmark 16 5000 avgt 5 251214.457 ± 40224.490 ns/op
TheBenchmark.toyBenchmark 8 5000 avgt 5 319809.483 ± 560434.712 ns/op
TheBenchmark.toyBenchmark 2 5000 avgt 5 477652.450 ± 1068570.972 ns/op
如您所见,分数实际上随着小数位数的减少而增加!我已经在 5000 点上尝试过,但是无论我使用多少点,它都保持不变。
为什么会这样?我认为浮点数越多,需要的计算量就越多,尤其是平方根。
为了增加小数位数我创建了这个函数:
public static double generateRandomToDecimalPlace(Random rnd,
int lowerBound,
int upperBound,
int decimalPlaces)
final double dbl = (rnd.nextDouble() * (upperBound - lowerBound)) + lowerBound;
return roundAvoid(dbl, decimalPlaces);
public static double roundAvoid(double value, int places)
double scale = Math.pow(10, places);
return Math.round(value * scale) / scale;
我在某个范围(-100 到 100)和特定小数点之间随机生成点:
@Param("16", "8", "2")
public int noOfFloatingPoints;
【问题讨论】:
您如何增加/减少小数位数?请显示您用于基准测试的代码。 @GilbertLeBlanc 我现在把代码放在那里 【参考方案1】:double
类型是二进制、固定长度的数据类型。无论您的数字有多少个小数点,它总是使用 64 位来表示一个值。此外,由于它是用二进制编码的,它甚至不使用小数点。它使用使用 base-2 算术的浮点数。
【讨论】:
我明白了。那么我是否正确地认为,考虑到这一点,二进制点的精度对计算时间绝对没有影响?即使做平方根? 没错。在较旧的机器(例如 1970 年代的大型机)上,可能使用float
(32 位)而不是 double
(64 位)会更快,但现在 float
和 double
使用相同的数学协处理器(部分Intel/AMD 芯片)使用 80 位进行所有计算,然后将其存储在 double
或 float
变量中。因此,任何double
值都将花费相同的时间来计算。以上是关于为啥增加小数位数不影响欧几里得距离的计算时间?的主要内容,如果未能解决你的问题,请参考以下文章