输入法词频优先级的算法大家谈 ( 积分: 0 )

  • 主题发起人 主题发起人 hys_peter
  • 开始时间 开始时间
H

hys_peter

Unregistered / Unconfirmed
GUEST, unregistred user!
如同输入法的词频输入一样,经常出现的会自动排在第一位;
1.建立一备份文件,把所有字词的出现频率定为零,然后用户选种的字词,添加到备份文件,自动加一,下次出现,频率高的往上排,例如 拼音"shu"对应的字为"书","树",当用户选择"树"后,在备份文件中添加"shu@树=1"下次再遇到"树"字排序会比"书"靠前;
不知各位通人还有其他的好算法吗?
 
如同输入法的词频输入一样,经常出现的会自动排在第一位;
1.建立一备份文件,把所有字词的出现频率定为零,然后用户选种的字词,添加到备份文件,自动加一,下次出现,频率高的往上排,例如 拼音"shu"对应的字为"书","树",当用户选择"树"后,在备份文件中添加"shu@树=1"下次再遇到"树"字排序会比"书"靠前;
不知各位通人还有其他的好算法吗?
 
这也太恐怖了吧,所有的字词那是个什么量级的文件啊?性能肯定是个问题,打起字来CPU还不百分之百的占用率啊,我觉得就是用键组合,配合第一个字就行了。
先有一个空文件
第一次使用输入法的时候,如果没有刻意选择,则不记录。
如果象你所说的shu,本来“书”在前面,但是操作者使用了“树”,就在这个文件中记录
键值:shu, 字:树
下次再输入shu的时候就直接先调用这个文件看看有shu就把字的值“树”取过来。
 
咱俩是一个意思,我说的备份文件就是空文件,但是随着使用时间的增长词会越来越多,所以,还得需要优化
 
关注此题
 
问题不会很严重吧。。。。输入法一定是用hash表了
a 阿啊呵嗄锕
ai 爱埃艾癌挨哎
ao 奥澳熬敖
hash表记录a ai的起始和结尾位置 比如a是0 4 ai是5....10 ao是11...15
汉字一般认为有8000多个。。每个同音字应该不会超过200个
每当打字的时候 比如打ai 查Hash表 得偏移5和10 打开字库文件取出第5个到第10个字
存放到一个数组中。。。显示出来让用户选字
之后用户选字 得到选字后 先打印到屏幕
之后我们能知道用户选的是第几个字
比如打 艾
在这个数组是第2个 (从0开始) 记录下来
之后就把这个数组写回字库文件 用修改模式 当然从偏移10开始写
写的第一个当然是第2个字
之后按顺序把剩下的写在后面(分2档写 大于等于2 小于2)
之后就是下一个字
因为每次数组的长度不会变的。无论怎么变顺序。。所以写文件不会引起文件空间重新分配。。。
也没有数组移动操作 就算大于200个元素 速度应该也是很快的
可以在切换输入法的时候把字库放到内存中。。修改在内存中完成。。切换的时候再写成文件
这样速度应该更快
 
如果考虑词的话 每次同时出现1000个待选以上情况也不多吧。。。
就算都是4个字的词 也就8000字节
用上面的方法没有内存重分配问题 在内存中覆盖(或改写)8K数据的速度应该是感觉不出来的 放到硬盘也感觉不出来。。。
目的就是避免内存重新分配带来的巨大时间消耗
还有一个问题 是自动学习词汇的问题 用户打得越多记得越多 原来没有的词也记住
这个可以在hash表里弄大点
比如
a 阿啊呵嗄锕
ai 爱埃艾癌挨哎
ao 奥澳熬敖
hash表记录a ai的起始和结尾位置 比如a是0 999 ai是1000....1999 ao是2000...2999
就是说预留一些 就算每个音有1000个字或词 一共也不会超过200种拼音组合 每个词给8个字节
也就是1600000 近2M的文件 通过hash表不用全部读取 每次读取一段 所以字库文件再大也没有问题。。。
微软拼音不是22M么 估计至少有10M是字库词库吧
紫光拼音就更BT了 100多兆。。。
 
貌似没有分啊。。。。说错了大家给与指正
欢迎讨论。。。。
 
后退
顶部