匀称图形的测试数据, 建议修改标准.

[denghui0815]

http://softwarecontests-zho.intel.com/threadingchallenge/

图形是由一组节点（或顶点）和一组边组成的结构；每条边连接两个节点，并由这两个节点确定。Solomon W. Golomb 创造了“匀称图 (graceful graph)”一词，来指代可以“ 以匀称比例编号”的任何图形。本月的问题是：输入一个图形，确定该输入是否为匀称图；如果是，则输出图形节点和边的匀称编号。

图形的匀称编号具有以下属性：
每个节点都标有一个独特的非负整数
每条边都标有节点标签之差的绝对值
边的编号必须是介于 1 和总边数之间的唯一值

某些匀称图采用单个节点编号方式，有些可能采用多个节点编号方式。您的程序只需要列出节点和边的一种匀称编号方式。

关于输入文件的描述：在应用程序开始执行后，将输入文件的名称以命令行参数的形式赋予应用程序。该文件包括许多行，其中含有图形中要分析和标记的边。输入节点用两个介于“A”到“Z”之间的大写字母表示。一个输入行包含四个大写字母，第一、二个字母表示第一 个节点，第三、四个字母表示另一个节点，从而确定相应边。“文件结束”表示图形输入结束。

输出：输出采用标准输出形式。应当有相应说明指出输入图形是不是匀称图；如果是，则提供节点的匀称编号和边的相关标签。匀称图的节点应当按照节点名称以升序输出；边应当按照边标签以升序输出（不需要输出与输入时一样的边名称）。

输入示例：（包括四个节点的完整图形）

AABB
AAKK
AAZZ
ZZBB
BBKK
KKZZ



输出示例：

此图采用匀称编号方式。

节点：

AA 0
BB 6
KK 4
ZZ 1

边：

AAZZ 1
BBKK 2
KKZZ 3
AAKK 4
BBZZ 5
AABB 6

计时：如果不想将 I/O 时间记入应用程序执行时间，则应包括具有以下作用的计时函数调用：当读取输入文件后立即启动，在开始打印最终结果（和内部执行时间）前一刻停止。否则，裁判将使用时钟时间。

一组测试数据
AABB
BBCC
CCDD
DDEE
EEAA
AAFF
BBGG
CCHH
DDII
EEJJ
FFHH
HHJJ
JJGG
GGII
IIFF

共10080种填值方案

另外一组测试数据
AAAB
AAAC
AAAD
AAAE
AAAJ
AAAK
ABAC
ABAD
ABAF
ABAG
ABAH
ACAF
ACAH
ACAJ
ACAK
ADAE
ADAG
ADAI
ADAJ
ADAK
ADAL
AEAH
AEAJ
AFAH
AFAI
AFAL
AGAH
AGAJ
AGAL
AHAI
AHAK
AIAJ
AIAK
AIAL
AJAK
AKAL

无法计算填值方案种数

[haojn]

我也一直在考虑从分析图的特性入手降低复杂度，但还没有实质进展
单线程纯搜索的算法我已经做到nosol5用14.1秒，提升空间不大了

看到s1g1ll算Paley 17也只用了300多秒，我运行4个小时都没结果...
难道用了全局优化

[AutumnSky]

问一下，如果是多连通图，好分析么？

[瓶盒]

haojn未加任何剪枝纯搜索真的只用了6秒吗？
我的C1.8G的机子搜了半个小时，才几千个结果。

[haojn]

对，不过机器比你的要强一些。当时用的是Q6600@2.4G，单线程，ICC的编译器
以顶点编号作搜索，只要边标号不重复就搜下一个顶点

[dsdsdds]

对于这组测试数据

一组测试数据
AABB
BBCC
CCDD
DDEE
EEAA
AAFF
BBGG
CCHH
DDII
EEJJ
FFHH
HHJJ
JJGG
GGII
IIFF

共10080种填值方案

我手画了一下，是一个将两个五角星用五条边连接起来的图，所以我觉得解的数量不是10080。

[dsdsdds]

应该是一个比 10080 更大的数。

[haojn]

10080不会有问题的，这个是未加任何剪枝纯搜索出的结果，同构图重复计算

[瓶盒]

多谢haojn了，我的机子试了下需要36秒，这种搜索应该也算剪枝了吧

[yangyun10]

10个顶点，15条边的，算不出正确结果，不知道错在那里；

LZ给个正确的标记例子，算是抄答案了。

肯定不是纯搜索，排列组合一共有2000亿以上，符合题目要求的有1亿多，数学上该有方法把方案可能存在的区域减少到可接受值（比如1000万以下），才可能6秒完成。

[denghui0815]

Node Count: 10
Edge Count: 15
NODES:
AA 15
BB 0
CC 14
DD 4
EE 2
FF 3
GG 11
HH 10
II 12
JJ 5
EDGES:
GGII 1
DDEE 2
EEJJ 3
CCHH 4
HHJJ 5
GGJJ 6
FFHH 7
DDII 8
FFII 9
CCDD 10
BBGG 11
AAFF 12
AAEE 13
BBCC 14
AABB 15
File: dat.txt3 Time: 0.000183 seconds

另外附上测试数据
AABB
BBCC
CCDD
DDAA
DDEE
DDFF
EEFF
FFGG
FFHH
CCHH
DDHH
BBGG
AAGG
BBFF
AAFF
CCEE
EEHH
GGCC
EEGG
BBHH
AAHH
HHII
BBII
EEII
GGII
AAII
CCII
DDII

只有4种标记方案

[denghui0815]

clayb的paley13.txt

HGGS
SMLJ
AMSS
DKHG
HGBT
SMBM
AMDM
DKAR
HGSM
SMAM
AMDK
DKBT
GSAR
LJBK
SSHW
GSSM
LJAM
SSDK
GSLJ
LJSS
SSHG
ARBT
BKBM
HWDM
ARLJ
BKSS
HWHG
ARBK
BKHW
HWGS
BTSM
BMAM
DMDK
BTBK
BMHW
DMGS
BTBM
BMDM
DMAR

[yangyun10]

谢谢，还是图论没学清楚，找了很多错误方案计算

[jfguo]

这个月比较忙，这两天刚刚写了一个单线程的程序
测了一下nosol和bench，结果不是太好。
cpu: PD925
mem: 1G
大家bench的结果都是多少？

nosol bench
1 9.64s 9m29s
2 7.49s 9m51s
3 8.04s 8m38s
4 7.49s 5m14s
5 10.26s 10m7s
6 12.46s 12m
7 8.51s 8m52s
8 7.92s 4m28s

[denghui0815]

楼上的结果有问题吧 bench 的时间跟nosol的时间应该不会差别这么大

[jfguo]

使用TBB后，nosol几乎每个case时间都减半。
bench用时虽然少了很多，但还是很不好，
如bench1现在用时3m16s。
估计是算法的问题，明天要是有时间再调调。

[haojn]

denghui0815，你算paley13用多长时间？

[denghui0815]

paley13 两个线程 T2050 大约3秒

[haojn]

非常快啊
我在Q6600@3G只能到2.5秒

[denghui0815]

其实 都有随机性的

[haojn]

随机性确实很大，搜索空间太大了，全看解的分布和搜索顺序是否match了
要是像你说的，输出解数目就好了


我看了一些关于对称图形做graceful标号的文章，但里面都是对已知对称模式的图形做搜索剪枝，比如wheel
似乎还没有很好的方法对任意图形的对称性做出判断