近日写NOIP2015的运输计划,第一眼看就是树剖。 O(nlog3n) ,肯定过不去啊。听说可以差分,那就差分吧。
于是需要一个差分数组,需要预处理LCA。
这两天写的LCA好像还挺多的,那就上倍增吧。
最后一个毒点, n=300000,m=300000 ,卡的不要不要的。
那就上ST表吧,人家查询可是 O(1) 的。
完了比倍增还卡。
看看题解,什么son啊,top啊,这不是树剖么。仔细一看,原来只是用树剖求LCA……我还真是没见过。
写写写,果然快了不少。然而还是卡……后来事实证明,递归深搜还是比较慢的,处理出来DFS序在外面搞足足省了一半的时间……不过二分的次数应该不超过30啊……这差距有点大。
不过关键的还是那个LCA的预处理方法。树剖的代价,应该是 O(log2n) 啊,倍增啥的都只要一个 log ,这好不科学。
万一是数据的问题呢?
然后我就测了一发。
每组数据的flower和link是输入的系数,表示生成菊花图或者链的程度。
分别写了树剖(link),倍增(2),ST表(ST),还有HeRaNO和ghb的两个Tarjan。Tarjan这玩意儿我从来都没写过,不喜欢离线。
1000000的点,1000000的查询,随机。
Test #1: Making Data…
flower:0
link:0link:
1.0596492:
1.282305ST:
2.308755HeRaNO:
0.749377peter_819:
1.240446
Test #2: Making Data…
flower:0.3
link:0.5link:
0.9007932:
1.204793ST:
2.253253HeRaNO:
0.662086peter_819:
1.243128
Test #3: Making Data…
flower:0.3
link:0.8link:
0.9112722:
1.234927ST:
2.262454HeRaNO:
0.677657peter_819:
1.263069
Test #4: Making Data…
flower:0.5
link:0.8link:
0.7889342:
1.170736ST:
2.202955HeRaNO:
0.667748peter_819:
1.221630
Test #5: Making Data…
flower:0.9
link:0.9link:
0.7022052:
0.977679ST:
2.072199HeRaNO:
0.631767peter_819:
1.161829
Test #6: Making Data…
flower:0
link:0.9link:
1.0628542:
1.514389ST:
2.325562HeRaNO:
0.781017peter_819:
1.320920
实在是大跌眼镜。以为很慢的树剖果然是最快的,以为很快的ST表居然是坠慢的。
而且以为树剖这种东西应该在一条链上跑的是最快的,没想到所有的算法都在菊花上最快……
HeRaNO自带小常数,又是 O(n