很奇怪！很奇怪！！

wang2lang

很奇怪.zip (5.9 KB, 下载次数: 495)

2012-8-7 14:52 上传

点击文件名下载附件

附件是一个自定义短语的部分，有关元素周期表的。

很奇怪的是，当我键入oys或oyszqb或ohxys往后翻页时，却发现第60号元素钕(nǚ)，№60，Neodymium，Nd，原子量144.242的候选序位却排在了第117号Uus和118号Uuo之间去了，而不是在自定义短语中安排的第59号元素镨(pǔ)和第61号钷(pǒ)之间。
真是奇怪！

有心人不妨试一试……

krsun

效果一样^_^

wang2lang

呵呵。不必后面缀一个分号。隔一个注释行就OK了！
szxh=1;2;3;4;5……
;注释行
szxh=41;42;43;44……
;单独一个西文分号作注释行就行
szxh=81;82;83;84;85;86……
;

kingdick

嗯。

野风

回复 14# kingdick

回来了？

kingdick

一周没上网，看看发生了什么。

krsun

楼主客气了^_^
好久没有上来了，上来就解决了一个问题。还是蛮开心的。

wang2lang

感谢krsun 版主。
分行定义时，后面椎一个西文分号，是个解决办法！

krsun

另外建议楼主是不是可以考虑将元素号码放在前面，这样看起来比较整齐一些。当然了如果楼主有其他考虑你就还是按照楼主这样处理吧。^_^

krsun

这个问题原因我觉得是自定义短语的单行和多行定义有冲突造成的。

通过测试发现类似楼主这样定义的时候

oys＝氢(qīng)，№1，Hydrogen，H，原子量1.00794;........;钕(nǚ)，№60，Neodymium，Nd，原子量144.242
oys＝钷(pǒ)，№61，Promethium，Pm，原子量145;......暂无译名，№118，Ununoctium，Uuo，原子量293

前面一个定义中最后一项末尾应该再加上一个分号作为这个单行定义分项的终结。不然解析程序可能会认为你这个分项是多行定义。从而造成解析的混乱。至于为什么这个被消减的项会跑到倒数第二个去了，我感觉是算法处理的时候可能采用了递归调用，这一项因为一直没有匹配出来，就在最后简单处理了。开发组在说明单行多分项定义的时候没有考虑到用户可能下面还会用同样的短语名继续定义，由此造成了这样的问题。

下面是加入了分号的输出情况，排序正常了：



为了说明问题，我再举个例子
比如你做以下定义:

osy=1;2;3;4;5
osy=6;7;8;9;0
ABCD

然后输入osy
那么0ABCD会成为一项。5被放在了下面一条短语的倒数第二项（其实此时5也是被按照多行定义解析的只不过因为它下面没有其他的内容，因为osy=被解析为另一个短语定义的开始），0和ABCD被解析成多行定义。



多行定义和单行定义本身就存在一定的冲突，希望以后能逐渐完善吧。

ljdqe

请试试在你的短语中加入以下内容：注意第一条是oszxh，包含了数字1-118，后面的是分行写的szxh

oszxh[数 ...
wang2lang 发表于 2012-8-7 17:59

    你是发现了一个问题，但是否会影响到程序的不稳固，只能让开发组去研究了。即便不影响程序的稳定性，至少说明对这部分的处理，算法上还有待改进。

wang2lang

请试试在你的短语中加入以下内容：注意第一条是oszxh，包含了数字1-118，后面的是分行写的szxh

oszxh[数字序号]=1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40;41;42;43;44;45;46;47;48;49;50;51;52;53;54;55;56;57;58;59;60;61;62;63;64;65;66;67;68;69;70;71;72;73;74;75;76;77;78;79;80;81;82;83;84;85;86;87;88;89;90;91;92;93;94;95;96;97;98;99;100;101;102;103;104;105;106;107;108;109;110;111;112;113;114;115;116;117;118
szxh=1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40
szxh=41;42;43;44;45;46;47;48;49;50;51;52;53;54;55;56;57;58;59;60;61;62;63;64;65;66;67;68;69;70;71;72;73;74;75;76;77;78;79;80
szxh=81;82;83;84;85;86;87;88;89;90;91;92;93;94;95;96;97;98;99;100;101;102;103;104;105;106;107;108;109;110;111;112;113;114;115;116;117;118

留意一下40和80的候选显示位置。

这应该是紫光的一个BUG，希望开发组重视。候选序位混乱，可不是小问题，应该涉及到程序算法的内核了。深入研究解决，或许可以由此挖出一些隐藏的不稳定因素。

wang2lang

似乎找到了规律：
当紫光的短语做类似如下的定义，如
szxh[数字序号]=1;2………39;40……78;80……117;118;119;120
这是可以正常候选显示的。候选顺序一如定义安排的那样。

可是如果将那些数字序号换成其他字符数较多的内容，比如每个数字序号换成诸如“红楼梦第一回：甄士隐梦幻识通灵，贾雨村风尘怀闺秀”
“第二回：贾夫人仙逝扬州城，冷子兴演说荣国府”“第三回：贾雨村夤缘复旧职，林黛玉抛父进京都”之类的内容
szxh[数字序号]=红楼梦第一回：甄士隐梦幻识通灵，贾雨村风尘怀闺秀;第二回：贾夫人仙逝扬州城，冷子兴演说荣国府;第三回：贾雨村夤缘复旧职，林黛玉抛父进京都;……第一百二十回……
这些分号分隔的120个候选，就将是一段很长的内容，紫光将显示不了，会自动截断一部分（比如从第40回截断），并将被截断部分作为一整条内容（第41～120回及用于分隔的分号被作为一整条内容）。

于是我们可以做多行定义来解决这个问题，如
szxh[数字序号]=1;2………39;40
szxh[数字序号]=41;42………79;80
szxh[数字序号]=81;82………117;118;119;120

可是这样的话，候选显示就混乱了。
混乱显示的大致规律见下图

wang2lang

是很奇怪。元素钕单独写一行，而不是用分号与其他的分隔，也一样。

这里面或许隐藏着紫光不太稳固的原因……

再次改写之，将钕及其前后的都另起一行如下

oys=……;铯……;钡……;镧……;铈(shì)，№58，Cerium，Ce，原子量140.116
oys=镨(pǔ)，№59，Praseodymium，Pr，原子量140.90765
oys=钕(nǚ)，№60，Neodymium，Nd，原子量144.242
oys=钷(pǒ)，№61，Promethium，Pm，原子量145
oys=钐(shān)，№62，Samarium，Sm，原子量150.36;铕(yǒu)，№63，Europium，Eu，原子量151.964;钆(gá……

却发现：钕(nǚ)正常了，可【钷(pǒ)，№61，Promethium，Pm，原子量145】跑到后面去了

wangyanhan

附件是一个自定义短语的部分，有关元素周期表的。

很奇怪的是，当我键入oys或oyszqb或ohxys往后翻页时 ...
wang2lang 发表于 2012-8-7 15:01

是只勾选了这个短语库试的。
有这么回事，“钕”到最后去了。

wang2lang

回复 3# renkai@yahoo.cn
自定义短语文件中，元素钕是安排在元素镨之后 元素钷之前的。
可是键盘输入的候选中，却到了最后面去了

renkai@yahoo.cn

看不懂

wang2lang