思考一个模式识别与机器学习相关的问题

(上高中时产生的想法,但不知道有没有人做过相关的研究)
我们知道,模式识别与机器学习方法在文字扫描识别和手写识别领域有着非常成功的应用,我们可以通过断的指出机器识别手写文字的错误来让机器逐渐适应我们的手写字体,从而不断提高机器的识别正确率。但这种识别的一个弱点在于,我们总需要人为的指出机器识别的错误,机器是不可能自己觉得自己有错的。
设想一种有前提约束的条件,例如,要识别一串文件,里面的数字5和字母S很像,机器并不知道到底应该是哪个,如果我们事先已经告诉机器,这里面只有数字没有字母,那么机器会很“自信”的认为结果应该是5,即使它的样子再像S也没关系。这也就是说,通过事先制定好的约束条件,可以起到提高识别正确率,树立机器自信心的作用。
我的想法是这样的,比如我们拿到一厚本打印好的程序代码,但没有电子的源版,现在需要把这些代码输入计算机器并让它编译运行,人工来做工作量是很可观的,而机器去识别的话,基本上不会得到能直接使用的代码,比如全角标点与半角标点,比如冒号与分号等,这些因素导致识别后的代码必须进行人工校对整理,才能够使用。但是我们知道,计算机程序的源代码在语法是上有着非常严格的要求的,不满足语法的代码一定会被编译器毙掉,那么,我们能不能把这种即定的“语法”作为事先制定好的规则,从而指导机器进行识别,让机器自己能够分析出正确的结果呢?
比如,一段打印好的代码:
void MyFunc()
{
   a++;
}
这是一段符合C语言标准的代码,假如由于打印的关系,使得纸面上“a++”后面的分号不是很清楚了,看上去更像一个冒号,如果按照现有的识别程序来做,可能识别的结果就会成为“a++:”,但是学过C语言的人都知道,这样写是不符合C语言语法的,把这样的程序送去给编译器肯定是不能通过的。而如果我们的识别程序在识别之前就已经知道了C语言的语法,知道这个地方不能是冒号而可以是分号,那么就会自动的把它更正为分号,因为有编译器这位铁面包公的存在,识别程序是不可能蒙混过关的。
可以发现,这里与传统的文字识别相比增加了“程序语法”这个输入项,这一项作为我们人为输入给计算机的先验知识,用来指导和约束识别程序的行为,从而有望把识别正确率提高到接近100%的程度。
这里说的是一种比较理想的情况,它假设除了这个冒号/分号以外都已经被正确识别了,程序才能够通过语法来辨别这里该是什么号,实际情况下疑点会更多,也就更需要计算机做智能化的分析。实际操作起来还有其他复杂的问题,一方面是如何有效的表达程序语言的语法,另一方面也要求输入的原件不应该有太重大的错误,如果这里出现的即不是冒号也不是分号而是一堆汉字,那么计算机就分特了。
还有一个问题,就是计算机为什么知道冒号不行就试分号呢?这里我想把它分为两种情况。
第一种情况下,识别程序可以清晰的分为两部分,第一部分按照传统的识别方法得到识别结果,比如通过计算,它认为这里是冒号的可能是50%,是分号的可能是48%,其他为2%,那么取可能最大的,也就是冒号了。这个结果作为第一部分程序的输出,同时也是第二个程序的输入,第二个程序事先要非常清楚C语言的语法,同时,我们还人为的制定了很多相似规则,例如告诉计算机,冒号和分号很像,如果一个不行可以试试另一个,在这种情况下计算机根据人为制定好的规则去判断到底应该是哪一个,从而得到正确的结果。
第二种情况下,识别程序并不直接得到一个固定的结果,而是把可能性大于某一阈值的结果都列为候选,例如这里冒号和分号的可能都很大,虽然冒号更大一些,但我们对可能都大的结果并不进行排序,而是公平对待,让编译器说了算。这时只有分号可以得到编译器的认可,那么结果就是分号了。这种情况下人事先不需要告诉计算机哪个符号和哪个符号更相似,而是让计算机自己去学习,再加上编译器的语法限制,理论上将得到接近100%的正确率。
当然,这两种情况哪个更好我还很难判断,也许更好的办法是它们的结合,至于如何结合,如何去实际操作,就都有待进一步的研究了。
需要说明的是,这里所说的编译器并不是指真正的C语言编译器,因为真正的编译器要求太严格了,比如前面的程序可能只是某个大程序中的一部分,作为全局变量的a它的声明就不出现在这里,要把这样的程序送去给编译器除了一堆error还能得到什么呢,这里真正需要的只是一个比编译器宽松很多的“语法检查器”,只要能检查出所识别出的结果是否满足语法就可以了。

你可能感兴趣的:(c,工作,语言,编译器)