在最近的项目实验中，我的工作是实现一个具体的置信度传播算法，为了速度快、并且运行稳定，我用c++语言编写代码，并且在linux环境下编译，采用的数据格式是gml。gml格式是国外科研人员广泛应用的数据格式，结构如下：

。。。。。。，这里只展示三个节点。

。。。。。。，这里只展示三条边。

其完整的包含了结点信息，边信息，内容信息，groundtruth和网络有向信息。

     但是由于一些数据集不是gml格式，所以我需要写一个转格式脚本。我将转换完的gml数据集应用在算法中，利用nmi评价指标对算法结果进行评价，发现效果非常不好。但是没有经过我转换的gml格式，也就是本身就是gml格式的数据集，效果非常好，并且是同样规模的网络。

     根据问题的表现形式，我确定了我算法部分编的没问题，因为对于其他的本身就是gml格式的数据集，效果很好。我本能的就想到是不是我写的转格式脚本出错了，我迅速的检查了一遍，没有发现错误。没办法，我只能从算法入手，刚刚排除了算法实现细节的问题，那么很有可能是计算精度nmi时出现了问题。我猜想可能是算法输出结果的结点编号没有和真实的groundtruth结点编号对齐，也就是说将第一个结点的实验结果和第二个结点的真实结果进行比较了，如果是这样的话，结果肯定不会好。为了验证这个想法，我将每个结点的度值输出出来，发现确实和原来的顺序不一样了，原来的二号节点变成了一号节点，后面的所有结点都前移了一位，而最初的一号节点变成了最后一个结点。这让我很费解，因为我的算法代码并没有调整结点顺序，并且别的gml格式的数据集也没有这个问题，我反复思考，认为还是我的转格式脚本出了问题，这次我把我转换后的gml数据集和本来就是gml格式的数据集打开对比看了一下，试图发现它们的不同。结果真的给我找到了！我发现了一个统一的问题：在gml格式中，如果结点编号是从0开始，到N-1，那么表示边的结点编号也是0到N-1；如果结点编号是从1到N,那么表示边的节点编号也是1到N，就是说他们是统一的。而我转的gml格式就不统一，我的节点编号是从0到N-1，但是边的编号是从1-N。而我的算法是从读边开始确定结点的，它从1开始读的话就漏掉了我的编号是0的结点，只能把它放在最后。这导致了我的实验结果标签和groundtruth对不齐的问题，从而效果不好。

     通过这次错误，我发现我在做实验的时候，手太快，心太慢，就是在没有弄清需求的情况下，就动手做了，观察的不够认真，只求速度和效率，最终发现了问题还要自己从头找，更加拉低了效率，吃亏的还是自己。以后我要避免这样的错误，动手之前先把情况彻底弄清楚，做到胆大心细。同时也提醒使用gml格式的朋友们注意一下这个格式的特点，注意这个统一的问题。

关于使用gml数据格式的一点体会