以毫秒为单位计算图形的平均遍历时间会产生不可思议的输出？答案

【问题标题】：Calculating the average traverse time for a graph in millisecond gives an inconceivable output?以毫秒为单位计算图形的平均遍历时间会产生不可思议的输出？
【发布时间】：2013-06-24 16:00:52
【问题描述】：

我正在对图形中的搜索（在邻接列表和邻接矩阵之间）进行性能测试，以计算整个图形的平均遍历时间（以毫秒为单位）。

但是，输出给出了一个我以前从未见过的数字。下面是简单的测试算法。

   double startTime;
   double endTime;
   double processTime;

   double totalTime = 0;
   double averageTime = 0;

    for (int i = 0; i < 100000; i++) {


        startTime = System.nanoTime();

        search.DFS(5);

        endTime = System.nanoTime();

        processTime = (endTime - startTime)/1000000;

        totalTime = totalTime + processTime;
    }

    averageTime = totalTime/100000;

    System.out.println("PROCESS TIME in AdjacencyMatrix = " + averageTime + " ms");

输出看起来像 ;

PROCESS TIME in AdjacencyMatrix = 1.4765902999997995E-4 ms

当我只遍历一次时，输出会提供方便的数据，例如0.032344 ms。

【问题讨论】：

标签： java time double milliseconds

【解决方案1】：

即使您使用 double，您仍然会出现精度错误。基本上，浮点数总是十次方的数字之和。这意味着并非所有数字都可以精确保存。我猜这就是你的问题所在。

作为一种解决方案：将long 用于您的变量，这是System.nanoTime() 的返回类型。这个返回的数字总是一个整数。

【讨论】：

@Goacat 有一个很好的观点。我回答的第二部分仍然很重要。即使 Goacat 的答案是正确的解决方案，您也应该更改代码。
那么您的程序实际上似乎非常快。至少在循环中，要看到一些结果使用纳秒而不是毫秒。如果一次迭代非常快，processTime 将始终舍入为 0，totalTime 也加起来为 0。如果您对那些使用纳秒，则它不会为 0，并且当它最终舍入时，您的精度损失会更小。但是使用双重防御是没有意义的。
答案非常明确。现在我放弃了将 ns 转换为 ms 并使用 ns 作为时间测试的单位，它给出了精确的结果:)。谢谢你的回答:)

【解决方案2】：

数字只是写成浮点数。

1.4765902999997995E-4 = 0.000147659...

所以因为它是一个非常小的数字，所以输出是浮点格式以便于阅读。

编辑：澄清浮点数。这只是一种写数字的方式，通常被称为“科学记数法”。这只是编写非常大或非常小的数字的一种不同且方便的方法。在学校你可能会遇到这样的事情：

3,000,000 = 3 * 10^6 = 3E6

1,456,000,000,000 = 1.456 * 10^12 = 1.456E12

所以“E”只是表示*10^。如果数字很小，则在 E 之后使用负数，如下所示：

0,04653 = 4.653 * 10^-2 = 4.653E-2

0,00000134 = 1.34 * 10^-6 = 1.34E-6

0.000000000000000018 = 1.8 * 10^-17 = 1.8E-17

如果你想要更多的例子，你可以在这个wikipedia article右上角的框里

【讨论】：

我不知道 E 字符指的是什么？你能解释一下吗？而且我会考虑不超过 5 或 6 位数字，所以我想我必须摆脱它们。 :)
我编辑了这篇文章来解释更多关于浮点数的信息！ =)