基于欲望的人工智能(四)

本来想把这个系列之四写完。后来想想,其实能扩展出去的话题十分广阔。真的想探讨下去的话,很难说会是哪种情况:一种认真谨慎的课题,一种是轻松有趣的科幻小说。两个都是我们想到达的目标。可是真的是没有太多时间,所以干脆把几个月前写的大纲发出来吧。以后有机会,等 Peter 和 Sui 也有空了,我们重新回到这个讨论上来。如果可以论证,就做成一个研究或者实验;如果不行的话,就干脆写成科幻剧本卖给电影公司算了。不能做自己想做的事情,真是一种悲哀。

这里是前面写的  、

衍生的概念:

非欲望(恐惧)——遇到某件事情,让机器害怕。然后机器以后碰到这样的事情之前发生的事情,就会极力避免同样事情的发生。

例子:

1、通俗例子:把一个机器运行的目的定义为,持续运行下去(也就是活下去)-〉根据机器的机理需要定义一个最基本的愉悦集(对生存的愉悦)和一个最基本的恐惧集(对死亡的恐惧)

2、具体例子:这个想法最大的问题就是如何对现实世界建模,然后和人工智能相连接。其实为什么我们一定要把人工智能和现实世界相连接呢?一个机器人一定必须是真的一个行动于我们身边有物理特征的铜铁么?实际上我们可以在电脑内建立一个极度简单的虚拟世界,把各个集合都最小化。最小的只要有我们需要的最基本元素即可。然后让我们具有欲望的人工智能和这个虚拟世界来交互。这样下来,实现我们的这个人工智能成本会小很多,也许是可以实现的。

还需要的内容:具体一点的关于记忆的保存和相应的数据结构

要解决的技术问题:

1、记忆

2、速度

3、不断提高机器所处的离散时间和空间,最终和我们的现实世界的时间和空间相吻合,于是机器就可以参与到我们的世界来。

从西海岸到东海岸

坐在候机室,没有事情做。唯一能连接到的无线网络还是收费的。于是决定,打开电脑,开始无所谓地练打字。

这是一个繁忙的周五,解决了所有可以解决的 Bug 之后,我早早地离开了办公室。谢谢 Xuan 的送机,送我来到了造访了若干次西雅图的机场。

第一次来这个机场,是2005年的微软面试,那次是我第一次来美国。却因为面试行程安排太过紧凑,根本没有什么心情去逛这个美丽的城市,结果自然是带着失败悻悻而归。之后根本没有再想过有机会回来这个地方,根本没有想过这是一个开始我的第一份工作的地方。后来不知道从哪来的勇气,再一次向这个公司递交了我的简历。于是时间过得很快,我在 2006 年愚人节的时候,拿到了 Offer。于是在十多个月之前第二次来这个城市,这个机场。回想当时的状况,一个手提箱,一脸唏嘘,站在风中等候迟来的 Taxi。真的有点浪子的感觉。

今天却是第二次坐在候机室,是来了美国以后第一次离开我工作的城市,回到之前生活了7年的地方。虽然离开这里只有短短十多个月,感觉恍如隔世。印象里我还是麦大的一个学生,Hamilton 的一个路人。

(若干个小时之后)

我正在多伦多这个大都市的某个角落,正在睡前结束这段无味的文字。今天看到了我熟悉的 Tim Horton’s ,看到了熟悉的仿佛很是优惠但是超级唬人“Only $xx.99!“ 之类的街边广告,看到了熟悉的 Chinatown 主干道上的流浪汉,看到了熟悉的忙碌的市井面孔。

一切仿佛昨日。

我是一名矿工

当你在挖矿的时候,总挖到不同的矿,每次挥下铁镐的时候,都是一种期待,这次会是什么?意料之中也好,意料之外也好,总能给人惊喜或懊丧。《一个NPC的故事

这个故事在我很早之前还在玩 UO 的时候就读过了,然后昨晚再度温读了一遍。如果让我找一句可以描述自己目前生活的话,我会说:我是一名矿工。然后我会重复上面开始的那段话。

我相信即使是我们所处的这个所谓“现实”,和无论《黑客帝国》里面的 Matrix 还有上面故事中的那个虚拟的世界一样,都在一个箱子当中。这个箱子对我们来说,是无边的。

因为世界是无边的,所以我们这些生活在这个世界的物种可以接触的、可以发生的、可以感受的,也是无限的。于是不知是因此我们有了好奇心,还是因为好奇心有了这个“现实”,我们的世界有了颜色。

我很喜欢我的工作,尽管对很多人来说是枯燥的。每天面对的是一个箱子,然后噼里啪啦地按个不停。日复一日,年复一年。拆开这个箱子,里面放的其实并不是什么宝石,但是这个箱子让我们通往的是另外一个无限的世界。

每天,我可以在这个世界发现无数有趣的事、有趣的物、有趣的人。这个箱子于是有了同样我们世界所拥有的颜色。如果我们的“现实”是这样一个箱子,会不会有另外一个物种“它”,也在“它”闲暇之余,来到我们的这个世界,游荡在在我们每个人的身边?听一下超级星光大道里唱的那首 Joan Osborne 的《One of Us》。你会有同样的感受。

为什么要为一次毫无价值的收获而沮丧?同样在挖矿的你,是否仍然努力地期待你的下一个宝藏?

Use base class iterator in a derived class with a template

To tell the truth, I am still a newbie in C++. So I decided to take a evening and do a quick exercise. What I am trying to do is to write a class which uses the iterator from its ‘parent’ class:

 1: #include <vector>
 2: #include <iostream>
 3:  
 4: template <typename T>
 5: class myVector : public std::vector<T>
 6: {
 7: public:
 8:  void Test();
 9: };
 10:  
 11: template <typename T>
 12: void myVector<T>::Test()
 13: {
 14:  typename std::vector<T>::iterator i;
 15:  
 16:  for (i = this->begin(); i != this->end(); i++)
 17:  std::cout << *i << std::endl;
 18:  
 19:  return;
 20: }
 21:  
 22: int main()
 23: {
 24:  myVector<int> v;
 25:  v.push_back(1);
 26:  v.push_back(2);
 27:  v.push_back(3);
 28:  v.push_back(4);
 29:  v.Test();
 30:  return 0;
 31: }
 

The whole point here is the typename in line 14. That is the tricky part which took me a while to figure out. Without it the code won’t even compile. Now I can add all different kinds of sorting methods to myVector. Yes, I know it’s a bad idea. Just code for fun.

不能不说的秘密

秋天不知道什么时候已经等在了窗外 让门前的那棵屋树霎时间红了半个身子 一片突然掉落的霜叶 让人还以为是二月的花

天气变化的厉害 思绪和身子骨一样都不由地得瑟个不停 终于明白 为什么老毛对待敌人的时候 一定要用一招叫做秋风扫落叶的掌法 才稍微被风吹一下 我就吸着鼻涕 想起家来

Don&#8217;t write multiple statements in one line

… for several reasons:

  1. It doesn’t boost the performance.
  2. It doesn’t reduce the memory usage.
  3. It is hard to set a breakpoint while debugging.
  4. It reduces the readability.
  5. It is nothing to show off.

Counter example:

Don’t write multiple statements in one line for that, it doesn’t boost the performance and reduce the memory usage, but hard to set a breakpoint while debugging as well as reducing the readability, plus it is nothing to show off.

任何技术都是双刃剑

分不清楚电脑系统里的家长控制(Parental Control)功能是用来让家长去控制 的,还是控制家长的。反正刚刚听同事说,他家小学快毕业的小孩用这个很牛B的功能把电脑加了密,然后他怎么也登陆不了。他本身就是搞技术开发,可就是没辙。

BTW,说到家长,今天是老妈五十岁生日。小时候不懂事,让您费心了。生日快乐!

Something bad will never happen. Something good will eventually happen.

Wow, that is a long title. Yes, they are the famous two principles in Software Engineering I’ve learned when I was in ITB. It says that, the software you designed is stable, if in general

  1. It will never enter a undesired state
  2. If it unfortunately enters an undesired state, it will eventually back to a desired state later.

While it is realistically impossible to achieve the first goal, although software engineers are trying to reach it as close as possible, there are many ways to accomplish the second one. It sometime can be some procedures, which are what we called "backup plans"; it sometime can be some kind of self recovery mechanism; or, it can be proved that the software will eventually do something good. Here is the video version of the idea.

这个世界虽然没有叮当

gift……但是还是有很多神奇的东西。刚刚从邮箱里发现不远万里寄来的一个礼物,欣喜万分。

大家猜猜看这是个什么东西?

9/11 更新:

这个东西叫做i卡拉OK。只要接在水果牌的音乐播放器上,那个小孔出来的音乐就是消过原声的。然后对着另外一端唱歌,声音会自动融入消过原声的音乐里。上面那些按钮是调 key 的,所以不会有破音的机会。厉害吧?