• 6月3日



    检查post processor是否正确

    project 布局

    每次移动大小和的0.8倍(步长=0.8)

    麦库截图20140802085634296.jpg 

    1.0倍

    麦库截图20140802085922796.jpg 

    可见重叠现象仍然很严重


    把最大迭代次数设为100后

    不解算重叠

    麦库截图20140902090443359.jpg 

    左图迭代100次,步长1.0,可以正确解算(为什么commands半径不一样???因为这些元素自身大小也是依赖于布局决定)

    右图迭代1000次,interfaces位置发生变化

    麦库截图20140902090837828.jpg 麦库截图20140902093057281.jpg 

    步长改为0.2,也可以正确解算,但布局差异较大

    total time: 47031ms

    麦库截图20140902091105921.jpg 

    步长改为0.05,最大迭代次数1000,结果与0.2类似,但最小的instance位置突变,同时计算时间大大加长

    total time: 61141ms

    麦库截图20140902091417187.jpg 


    发现一个错误,每步总偏移量应该以重叠距离来解算,而不是以大小和

    麦库截图20140902093913843.jpg 

    此时结果与之前步长取0.05的时候近似,但所需迭代次数仍然为1000。为什么?

    迭代次数极大影响解算效率,需要迭代1000次时整个布局算法需要时间40多秒。

    原因是平均距离竟然为负数

    修改终止条件为平均大小的1e-4倍

    修改之后迭代次数变为47,效果与0.05时类似

    麦库截图20140902095235906.jpg 

    此时步长改为0.1,结果更加紧凑,但迭代次数升到1000

    麦库截图20140902095505312.jpg 

    步长改为1.1,迭代次数变为3,中间的几个项目全部被挤出来了

    麦库截图20140902095918046.jpg 

    尝试采用逐步增大步长的方法

    初始步长0.1,以后每次增大0.1

    结果与之前步长0.05时比较相近,只是上下颠倒了,此时迭代次数28次

    iteration times: 28, total overlap: 0.000366, avgSize: 280.807526, nData: 31

    iteration times: 32, total overlap: 0.000000, avgSize: 301.641815, nData: 31

    iteration times: 18, total overlap: 0.000000, avgSize: 282.926758, nData: 31

    为什么每次迭代次数都不一样???而且布局有时候会上下颠倒。

    total time: 2875ms

    麦库截图20141002101154531.jpg 

    初始步长0.05,以后每次增大0.05

    iteration times: 45, total overlap: 0.000000, avgSize: 267.664886, nData: 31

    total time: 3969

    麦库截图20141002102323171.jpg 

    初始步长0.01,以后每次增大0.05

    iteration times: 33, total overlap: 0.014465, avgSize: 279.421539, nData: 31

    total time: 4047

    麦库截图20141002102445093.jpg 

    初始步长0.01,以后每次增大0.01,与步长为0.05的结果极为相似

    iteration times: 157, total overlap: 0.022949, avgSize: 261.157440, nData: 31

    total radius: 4454.659668

    total time: 8734 ms

    麦库截图20141002102811843.jpg 

    初始步长0.001,以后每次增大0.005,interface竟然被挤出来

    iteration times: 124, total overlap: 0.024284, avgSize: 262.104980, nData: 31

    total radius: 4435.342773

    total time: 14875 ms

    麦库截图20141002103457250.jpg 

    初始步长0.01,以后每次增大0.02,增长到1.0之后不再增大

    结果与上图类似,但是总计算时间严重增大

    iteration times: 55, total overlap: 0.019897, avgSize: 269.209503, nData: 31

    total radius: 4654.736328

    total time: 21546

    麦库截图20141002103858453.jpg 

    初始步长0.01,以后每次增大0.02,但改为增长到1.1之后不再增大,计算次数差别不大,interface又被留在里面了

    iteration times: 134, total overlap: 0.025909, avgSize: 266.133820, nData: 31

    MDS layout: 62 msecs

    total radius: 4724.598633

    total time: 20797

    麦库截图20141002104219156.jpg 


    改良后的Qt creator布局,似乎比较混乱

    麦库截图20141402143432296.jpg 


    想解决布局混乱的问题

    把sparseFactor设为1.5

    iteration times: 15, total overlap: 0.000000, avgSize: 372.832916, nData: 31

    MDS layout: 15 msecs

    total radius: 7293.814941

    total time: 2421

    麦库截图20142302232315890.jpg 

    设为1.0后

    iteration times: 13, total overlap: 0.000000, avgSize: 370.338684, nData: 31

    MDS layout: 16 msecs

    total radius: 7270.781250

    total time: 2735

    麦库截图20142302232534406.jpg 

    可见变化不大,无法通过设置sparse factor直接解决


    尝试解决结果随机性的问题

    iteration times: 13, total overlap: 0.000000, avgSize: 367.751099, nData: 31

    MDS layout: 0 msecs

    total radius: 7149.822754

    total time: 3312

    麦库截图20142302232849218.jpg 

    iteration times: 13, total overlap: 0.000000, avgSize: 373.069000, nData: 31

    MDS layout: 16 msecs

    total radius: 7289.882324

    total time: 2672

    麦库截图20142302233003468.jpg 

    两次的统计数据竟然不同


    经过对比,发现symboltree竟然不同,但只是每个子symbol的出现顺序不同,总的符号数是一样的。

    怀疑多线程分析导致插入顺序略有不同,于是哈希表的条目顺序不同。


    但是顺序不同如何导致结果不同?

    估计与后处理的迭代有关

    取消后处理的力引导算法后,前后两次结果仍然不同


    发现词频向量的分量顺序不同了

    发现计算词频向量内积的程序错了,但是修改后仍然有随机性。

    直接去除词频向量内积算法代码,还是有随机性。

    是否与图布局算法有关?取消所有图布局,仍然有随机性。

    只用trivalLayout 可以保证







  • 相关阅读:
    pgspider sqlite mysql docker 镜像
    pgspider docker 镜像
    pgspider基于pg 的高性能数据可视化sql 集群引擎
    diesel rust orm 框架试用
    golang 条件编译
    Performance Profiling Zeebe
    bazel 学习一 简单java 项目运行
    一个好用node http keeplive agnet
    gox 简单灵活的golang 跨平台编译工具
    mailhog 作为smtp server mock工具
  • 原文地址:https://www.cnblogs.com/dydx/p/4236170.html
Copyright © 2020-2023  润新知