[Tips]2011-10-30

vim的paste mode 我们会遇到这样的情况: 需要从Vim之外的其它程序里拷贝一大段文字,然后在Vim里粘贴。 一般的,启动vim之后,按i进入插入模式 (Insert Mode),然后粘贴就行了。 但是当Vim的配置越来越多,插入模式下粘贴大段文字时可能会遇到各种诡异的情况。 因为这个时候的粘贴就相当于手动输入这些内容,于是各种映射 (Mapping) 就被触发了…. :set paste 可以启动一种paste模式,这个时候各种Mapping会被无视,各种自动缩进也无效。和在记事本里粘贴效果一致。 paste命令也符合Vim的通常规范 :set nopaste 可以关掉它。

siri和语音对话系统

Siri最近是相当的火,朋友Sigma最近的一片文章也有讨论她用到的技术。 Siri本身是一个语音对话系统。从输入到输出,经过语音识别,对话系统到语音合成。 想起自己当年的毕业设计就是一个对话系统,再看看Siri,觉得自己的东西太naive了 :] 系统前后两端的技术已经比较成熟了。 嘈杂环境下的实时语音识别可能仍然是一个问题, 但是Siri的使用环境使得她不需要去考虑这两点。 第一,用户不太可能在很吵闹的地方对着手机喊叫,这看起来太傻了。 第二,用户不需要Siri随时都监听输入。 这样一来,输入方面,误识别率大大下降了。 我很好奇的是Siri怎样做到和说话人无关的识别。 一般来说,如果期望识别系统有一个比较好的识别率, 都需要事先针对说话人对系统做一些训练。 对于不同的个人得到相应的特征偏移。 小词汇量的连续语音识别和命令式的语音识别对这方面要求不高, 但是大词汇量下的连续语音识别却是比较依赖事先训练。 难道是米国人的发音都很标准? 对话系统的核心是从文本到文本的这一段。 也就是从已经识别出来的,用户说的话,到Siri给出对应的反馈,这个过程。 这方面的研究也有很长的历史了。比如,很著名的图灵测试。 图灵测试里,机器的目的就是通过对话骗过裁判来相信它们是人类。 铜奖的标准是在文本对话上完成这个任务,银奖则需要语音上的完美模拟, 金奖就得面对面的自然交谈了。 目前还没有机器能达到银奖水平。 Siri,和图灵测试里的程序的不同之处在于她需要提供有用的服务。 如果Siri只是在跟你打哈哈,即使内容有趣,也不会有多大的用处。 所以Siri需要真正得理解对话的内容。 这就把人工智能多年以来的很多工作整合起来了,比如自然语言理解、专家系统、 甚至到逻辑推理。 这些才是人工智能的核心内容。 Siri和生活服务的整合方面则是语义网成功的应用。这方面我不太了解。 只是早先听说语义网在小的、定制的范围内有很成功的应用, 因为这一块需要比较大量的工程上的工作。 其实想法很好理解,而且大家都想过。 大家都曾经希望对话系统能够自发地去网上找缺失的信息。 但是机器没有办法直接消化处理搜索引擎的输出。机器需要信息按照机器能理解的方式去组织。 所以就有了语义网这个概念。网络上所有的信息都需要它的标签,机器可以理解的标签。 对于任何一个词,机器可以方便地找到相关的知识。 所以机器能知道”当我谈跑步时,我谈些什么” :] 我们可以隐隐感觉到语言理解是各个问题的核心,也是人工智能的初衷之一。 我们期望能和机器交谈。 当她们的外表越来越接近我们,她们似乎也应该有同样丰富的内心。 当我们向机器提出一个问题的时候,我们希望她能够给出满意的回答。 无论她通过什么手段。无论她叫什么名字。

[Tips]2011-10-19

两个Vim的小技巧 :] 其实就是两个正则表达式,刚好今天用到了,就记下来。 1. 有多行文本,其中有几行是URL,要保留这几行URL,其它的行删掉。 :g!/:\/\//d g本来是用来做grep类似的事情的,:g/pattern 会显示出符合pattern的所有行 惊叹号!表示相反,就是指选中的行是不符合pattern的。后面的/d是表示删掉选中的行。 2. 有多行文本,每行都是类似这样的 keyA=valA&keyB=valB&keyC=valC 现在要交换key和val的位置,变成 valA=keyA&valB=keyB&valC=keyC :%s/\=\/\2=\1/gi %s是全局替换,这个比较常用了。\是不太常用的anchor字符(锚字符),分别表示word的开始和结束。 \(..\)也比较常用了,可以保存匹配结果。\w*表示一个或多个word字符。 word字符包括a-zA-Z _ 和 0-9 :]

NSURL

码农Coding的时候有各种不好的习惯。 比如,不喜欢好好地看框架的文档,一旦找到某一个看起来简单易懂的接口,就一直用它。 如果需要之后的处理,往往简单粗暴。 我们以前管这种情况叫做“裸”。最近又不知不觉地写了比较“裸”的代码。 说实话,这个习惯得改,“裸”写的东西往往不健壮,不可读,效率还不高。成熟框架提供的直接可用的接口必须是第一选择。 NSURL是常用的类,用来描述一段URL的。 需要取得URL中不同部分的时候,我们应该用URL提供的接口, 而不是把它当做一个普通的字符串去手工分析。 比如: http://www.testurl.com:8080/subpath/subsubpath?uid=123&gid=456 NSURL *url = [NSURL URLWithString:@”http://www.testurl.com:8080/subpath/subsubpath?uid=123&gid=456″]; 下面是常用的几个接口,和它们的输出。接口意思都符合相关RFC里的定义。 [url scheme] http [url host] www.testurl.com [url port] 8080 [url path] /subpath/subsubpath [url lastPathComponent] subsubpath [url query] uid=123&gid=456 NSURL 英文版 :] NSURL is widely used, but sometimes we are not following the idiomatic usage. When it comes to access […]