拼音与五笔的统一

一直都被这样一个问题困扰着：既然以记忆预测作为输入法的基础构架，不同编码方式的输入法应该能统一在一个同样的框架下，因为语言蚊子本身是不依赖于编码的。

今天终于想明白了这个问题。

巨硬把同音字作为不同的字处理。其实可以不这样做。把拼音拆开成为子数组。然后在SeqNode上加一个modifier的标志，另外建一个数据库存储特殊的拼音序列，供匹配的时候查询，这样就可以依据字，而不是多音字，建立树库。可以实现不同编码输入法的词组、序列和频度的共享。

不过这是巨硬IV的任务了。巨硬III还是按照目前的算法继续下去，否则永远也无法完成可用版本了，改进永远是无止境的。

改动

据说这叫做AGILE。:)

对于这个小项目来说也许不是什么大问题，只是重写几个函数而已；如果是大项目，这个就要吐血了。所以我最终理解了，我在软件上最欠缺的是设计能力；不知道是不是有人能够做到一次设计不再改动的，至少对我来说这够匪夷所思的。

今天做了一个改动，摒弃了之前关于sequence of sequence的设计，抛弃在Sequence node中嵌入Sequence reference的做法。这主要是考虑到两点：一个是增加用户输入的随意性，比如用户输入嫁，可以提示鸡随鸡，输入嫁鸡，可以提示随鸡，输入嫁鸡随，可以提示鸡；另一点很重要的，是提高性能，只要抽出一个树就可以得到所有Node的展开结果，不需要查询其他树，这对于symbian或者wm这种以flash作为存储介质的系统来说非常重要。

低级错误

对于非职业程序员来说，经常重复低级错误就是编程的一大乐趣之一。我甚至在想，如果成立一个收录低级错误的网站，对Coder来说也许是很不错的去处。

今天就遇到了两个很低级的错误，其一是忘记初始化一个变量（把初始化写入Constructor这时就是一个好主意，当资源还不存在的时候这么干就不是一个好主意）；其二是没想到bitwise operator的优先级竟然不如+-*/。

ANYWAY，一边搭脚手架一边盖房子的过程开始了。

Coding的周末

这个周末写了不少代码。

上周看到同事演示了一下梅花在Dopod无键盘机器上的使用情况，设计得非常不错。不过我还是坚持硬按键的想法。硬按键和软键盘相比，后者的一个优势是可以动态更改键盘显示内容，梅花的作者在这方面颇有造诣。

巨硬III的算法是很独特的，目前我也不知道最终的结果是否如想象的好用，只能等做出来再看。我也在考虑用这个算法去解决一些输入法之外的智能问题，上周想好了一个例子，就是中国古老的围棋。

目前我越来越相信基于记忆树的预测方式是好过人工智能中广泛应用的盲搜路径的。但是关于严格序列的假设是否能击败Pattern识别方式就不得而知了。这里面还有一个Pattern形成的问题比较头疼，这涉及到人脑是如何发现和形成一个未知的概念。但总体来说，如果能克服这个问题，程序就可以象人脑一样去识别和学习了。围棋中有很多模糊的东西，这基本上就是一种概念形成的结果。在不同的阶段有不同的概念，比如布局、势和实地、形和子效、手筋、死活、先后、定势、管子等等。对形势判断的绝对的优劣是没有的，往往不同的人判断的结果不同，这是很有趣的一个方面。在人实际学习围棋的过程中，这些概念都是通过老师的教导和实际的感悟逐渐形成的模糊概念。

Doxys

今年对我的编程生涯来说简直是一个工具年。从MindMap工具MindManager，到UML工具DIA和Visio，都对我的coding方式有很大改善。眼看着年底将至，末世情结再现，这个节骨眼上，遇到了Doxys。

Doxys是一类被称为Documentation Extraction Tools的工具。它的工作原理其实很简单，就是在代码中有一些注释的约定，符合约定的注释可以直接被转换成html的文档。Doxys基于另一个DET项目Doxygen，不过我没试过那个，据说注释风格有些怪异。这是我目前看到的最好的代码维护工具。UML更多是用于理解代码，尤其是关键代码的，把所有的代码，尤其是例程，都UML出来很不现实。而且没有直接对应关系，要保持两个地方的逻辑一致，这才是维护的时候最难的地方。事实上，无论是MindMap工具，还是UML图，还是Word一类的RTF文档编辑器，都存在这个问题。从这个意义上说，Doxys是最好的方式。

UML的类图

在visio中这个称为静态结构图。

两年前我就买过一本UML。当时很起劲，还拉了一个朋友一起探讨code generation技术，UML的一个非主流的流派就是xUML， executable UML，换言之就是让UML可以自动生成可执行的程序。因为UML是平台无关的东西，这个想法很有吸引力，如果可行，程序员就不必探究平台差异的编程了。

UML的起源很复杂，所以学习UML就象学习计算机网络一样，林林总总的标准和意图，让这个技术变得不那么纯粹，甚至是颇为混乱。同样和网络一样，UML也是由为了解决很多工程上实际遇到的问题出现的，它更像一箱子组合工具而不是一把万能工具。

我一直被这样的问题困扰着：随着程序不断膨胀，类和函数越来越多，文件也越来越多；类之间的关系让人很头疼，无论代码还是文档都不直观。我也尝试过用powerpoint和mindmanager画了很多图，仍然不方便，所以这两天又把UML的书翻出来看了看。有点心得了。

好处：
1。UML类图可以很好的给程序结构一个总览。这是其他工具很难做到的。
2。UML有关于类之间的关系的严格定义，这比MindManager或者Powerpoint流程图那种不规范的东西好的多，规范的一个好处就是强迫你去按照严格的逻辑去思考，而不是在字面的意思上较劲。

缺点：
1。UML关于关系的定义需要花满多时间去学习。
2。UML并不是能表达所有的关系

底限：
1。不要试图把代码中的所有东西都放到UML中去，一些一望可知的东西和次要的东西不必放进去。
2。UML的目的是帮助理解代码，而不是和代码建立严格的逻辑关系或者生成代码，简单、直观、没有歧义是最重要的。

UML类图对开发进度的管理也因该有很大帮助，可以在代码和UML图之间往返工作：

1。先根据文档想清楚关键的算法和逻辑
2。在UML中画出除了基础类之外的类，尤其是那些需要在不同类之间作为参数传递的类，在开始的时候就统一一下，不要在写程序的时候不断添加这样的类。
3。把这张图画的平衡一些，把一些很小的、有强依赖关系的类合并到其他类中去，可以作为一个public成员存在。这样可以有效减少类之间的关系数量。
4。仔细考虑一下那些会很很多的类打交道的类，看看这样的类是不是功能很单一，是不是可以作为一个包中最大的容器类的一个函数存在，而不是作为一个类存在。

减少类之间的关系有助于理解和简化结构，当然，不能为了这个目的把类中大量添置操作，把不相关的操作都放到一个类中去，这也违反封装的独立性原则。要平衡类的操作数量和类的关系数量。

UML的活动图

这是一个特高雅的说法，说白了，就是传统的流程图，只不过更严密一些。

巨硬颇有几个搞脑子的流程，今天遇到的是第一个，Composition如何响应各种按键输入事件、分隔拼音、判断中英文状态，在Visio的帮助下，画了两个UML活动图，现在感觉比较清楚了。这两天睡眠不好，总是不能静心下来高效工作（别说让我喝静心口服液），今天画了两张图，感觉武功精进，状态在提升了。是个好的开始。希望这次代码工作能进行得比上次顺利。

BTW：这几天都在强制自己使用微软拼音输入法，如果能强制自己整句输入的话，准确率还是很不错的，只是不符合用户的输入习惯，而且万一匹配出错的时候，修改的代价很高。另外就是这个输入法对减少击键次数没什么帮助，比较适合touch typing。 

手机上的博客

测试。

巨硬III

可能很多人会以为这个标题是文字游戏，它不是。

过去的两周我已经仔细写完了巨硬III的逻辑文档，大部分问题都考虑完毕，这周开始进入代码阶段。上一次写代码大约是今年6-7月份，把这些代码翻出来看了看，庆幸当时的结构化设计，很多代码都可以重用，包括数组类、字串类、文件操作类；数据封装方面，原来的PalmOS数据库和记录操作代码可以完全不用修改，直接拿过来用；引擎和框架方面，上次的代码并没有最后完工，但是仍然有相当多的部分可以重用；只有数据结构方面，因为改动很大，需要全部重写。就代码量而言，现在保守估计应该有30%-40%的水平。

大家会问为什么跳过了2.0版本。对这个问题我会在软件发布的时候仔细解释，跳过2.0是有充分的理由的--或者把前面这个进度80％左右的版本称为2.0。3.0在逻辑上有质的飞跃。

关于输入法，目前应该说有两大流派：一个是规则派，大量使用技巧和规则，绝大多数基于词组、简拼、联想的中文输入法都是这一派的，这个路已经随着计算机中文应用进化了十几年，非常成熟，紫光拼音、拼音加加和新秀搜狗拼音都是典范；剩下的能做的改进已经很有限，无非是在词组和词频上做文章，以及增加一些特殊输入方式。当然这些输入法都有一些闪光点，比如词频调整和自动造词，确实方便。但是其发展空间的限制也非常明显，词组和词频的问题其实是非常个性化的，而特殊输入方式需要学习，我相信拼音加加的用户中90%以上都不会用到它的很多快捷输入功能。

另一类就是智能派（整句输入法），以微软拼音为代表，国内还曾经有个黑马输入法，以及口碑不错的智能狂拼。这一类输入法的理论依据很厉害，是贝叶斯模型。但是这个模型是否能适用输入法，是个疑问，我发现在现有的贝叶斯模型整句输入法中，或多或少都有些错误假设。这或者影响性能，或者不符合用户的心理习惯。

巨硬3.0不同于以上两类输入法，当然它不是说抛弃了上述输入法的优点，而是继承了传统规则派输入法的绝大多数优点，包括词频调整、自造词、简拼等等。但是在逻辑上，它大胆的采用了Jeff在On Intelligence中首次提出的Memory Prediction模型。该模型对用户来说的好处在于大大降低无效重码，在数字键盘设备上尤其明显。形象的说，MP模型就是词组的词组，再加上词组的联想，同时不要求用户的输入方式，比如连续输入几次蒲巴甲，即使是一个字一个字输入的，系统也会把他们组合成词。至于怎么从用户输入的序列中抽取出来组合的开始和结束，正是MP模型的闪光之处。实际上这个想法在2.0版本中就想实现了，但是直到最近灵光频现，才想明白了其中的一些关键问题，2.0中的一些思路是错误的，于是推倒重来。和商业软件相比，个人软件的魅力也许就在与此，It's ready when it's ready，你不需要把半生不熟的东西端上客户的餐桌。至于这个模型和现有模型能有多少进步。我的预测大概是这样的，如果是PC输入法，因为touch typing的速度是接近甚至超过人的口语速度的，用不用MP模型都没所谓；在thumb qwerty kb上，现有的巨硬和梅花都没有联想，如果采用MP能直接补足这个问题，如果是双手操作，速度应该能有50%左右的提升，如果是单手，还要多些，但是不会达到100%；在numpad kb上，传说中的Nokia神奇T9在我看来根本不怎么样，MP模型绝对可以让你shit in your pants。它应该可以让num kb超越现有qwerty巨硬的速度。

最后说说进度的预期，老实说，PALMOS是开发输入法最恶心的，没有好的系统框架，稳定性大成问题，debug也很困难，但是它在存储设计和运行效率上最好，而且我也最熟悉PalmOS开发，所以仍然从这里开始；最近也在看Windows Mobile和Symbian的开发，Windows Mobile开发也不难，有很好的输入法框架，就是效率上不知道怎么样，但是WM PPC设备的大内存是不错的，WM Smartphone就难受一些，不过总的来说差异不大；Symbian的系统在编程习惯上差异比较大，好处是FEP框架和C++类都很好，惟一的缺点是我对它的Stream类效率担忧，巨硬III的动态读取数据在M量级，频繁的读写操作系统能否高速完成是个未知数，如果要自己设计cache系统来解决这个问题的话，就太悲凉了。不过我现在就在使用E60，所以无论困难多大，我都会完成的。PalmOS的版本应该在春节前有Alpha，但是我不打算立刻发布；PalmOS版本完成之后会马上进入Symbian开发，我希望是在明年春暖花开的时候（大约4月吧）能同时发布PalmOS的QWERTY版、 Symbian的QWERTY（E61/E62）和NUMPAD（S60 3rd Edition）版。正式发布之后就进入Windows Mobile系统的移植，这个应该很快，再多花2个月吧。

 

SEQUENCE & FORGETTING

说起来有趣，一个以智能为目标的输入法设计，其核心的数据结构要考虑一个遗忘的问题。

巨硬一中没有特别设计遗忘算法，不过如果要实现的话并不复杂；因为巨硬一中没有设计记忆序列，所以所有词组可以放在26个序列中，至于为什么以S开头的字词和以K开头的字词都要遵守同样的空间限制，并不是一个非要解决的问题，即使K开头的字词浪费了存储空间，用户并不会有什么实际的使用障碍，浪费的那些存储空间也无关紧要。

但是巨硬二不同了，对于记忆序列的存储需要解决这个问题，不然浪费的空间就不是几百K的问题，而可能是几百M的问题。所以巨硬一的那种简单算法不再够用了。

解决这个问题有两个思路，一个是在记忆序列的时候记录使用次数，另一个是对所有记忆序列整体排序。前面一种方式比较可行。需要注意的地方是(1)排序的依据并不是使用次数，(2)该值的目的是遗忘，所以能记录有限的几次就可以了。基本上所有曾经被多次使用的记录都不应该被遗忘。