为什么增加小数位数不影响欧氏距离的计算时间？

Question

我正在尝试对 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;

Answer 1

double 类型是二进制、固定长度的数据类型。它始终使用 64 位来表示一个值，无论您的数字有多少个小数点。此外，由于它是用二进制编码的，所以它甚至不使用小数点。它使用基于 2 算法的浮点数。

为什么增加小数位数不影响欧氏距离的计算时间？

Why does increasing the number of decimal places not affect the computation time of Euclidean distance?

java

microbenchmark

k-means

euclidean-distance

jmh