GoGoGo~
Boost.Build v2的文档是看完了（不懂的不少……不过基本的倒没大问题了），接下来就轮到自己的论文了。负责论文的导师赵老师仍然没回信，暂时只得靠自己了。
不过关于论文方面的东西知道的甚少啊。路漫漫其修远兮，望吾将能上下而求索吧。
回归
一眨眼就到我考完试回到家 ，时间过得还真快啊。
试考得不怎样……不过我明白这是我付出的代价不够支付，钢炼和侑子小姐的代价说在我看来仍然是十分正确的。假期我应该顺便准备一下简历了。
这样我的大学剩下来的就只有一篇毕业论文了。论文的方向到现在我还是模模糊糊的，这个假期得挑时间先预习一下，不过21号考完试的当晚发给老师的邮件到现在还没有回信，有点担心老师不知道什么时候才会去收收邮件。如果放完假才收的话那么这个寒假就得靠我自己去预习我的论题了……
考完试后的这两天不时在泡Boost.Build V2的文档。这个我本来只是想用来方便点构建用Boost.Python写的extension的工具现在引起了我很大的兴趣，边看文档边写下了笔记，虽然这些笔记更有点像一个半桶水的菜鸟在翻译牛人们写的文档……
到目前为止理解都没大问题，只希望之后的章节我也能畅通无阻吧。
失眠夜看失眠书
国庆假期自己也跟着松懈起来了，主要征象就是早上7点睡晚觉……今天思前想后想了很多，最后决定不能继续这样了，还是收拢心情继续复习吧。
于是早早爬上床睡觉，结果睡了2个小时就醒过来了，醒来的原因……不知道，只知道我在半醒的时候脑子里面似乎在钻研些啥高深的问题，反正是连我自己也不敢相信了，我居然会在睡觉的时候还想起那些数学公式……
然后就失眠了……
第一，舍友说在床上看书是睡觉前5分钟做的事情，我又不想把台灯拿到床上，刚好kx正在奋斗他的wow，所以省事地灯都没关。结果可能就是这伪日光把我弄得睡不着。
第二，知道“敲键盘”这个动作英文是怎么说的吗？keystroke。
看明白了吗？是key + stroke。kx贯彻了这个“键盘是用来strike”的理念，毫不留情的打在他的键盘上……声音大之余暗暗替他键盘心疼一下。
不过人兴奋起来的时候，这些事情是常常是不会留意到的。
然后也不想在床上耗了，爬下来看书！结果越看越难睡得着……啥书？物理化学。
现在想来也觉得不可思议，1年前要我在考试前两天看这书我也嫌烦，现在看起来竟然还觉得挺有趣的。
一个人心境的变化真的可以很大的啊。
When he is desirous to gain his end.
不过有些事情我还没变的——我仍然很讨厌看政治。
The Game of Life
介绍
与其说是game，其实它更像是一个simulation，在1970年由英国数学家J. H. Conway提出的。The Game of Life的规则很简单：假设有一个无边界的矩形网格（我更喜欢把它称作宇宙，或者universe），这个矩形网格中的每个单元可被一个有机体占据（同样地，我更爱细胞这个词，或者cell）。被占据的单元称为活的（alive），未占据的单元称为死的（dead）。哪一个单元是活的要根据其周围活的邻居单元（neighbor）的数目而一代代（generation）地发生变化，规则如下：
- 给定单元的邻居是与它在垂直、水平或对角方向上相接的8个单元。
- 如果一个单元是活的，但没有邻居单元是活的，或者仅有一个邻居单元是活的，则在下一代，此单元就会因孤独而死亡。
- 如果一个单元是活的，且有4个或4个以上的邻居单元也是活的，则在下一代，此单元会因为拥塞而死亡。
- 一个活的单元，如果具有2个或3个或的邻居单元，则此单元在下一代仍是活的。
- 如果一个单元是死的，则在下一代，如果它不多不少刚好有3个邻居单元是活的，则此单元变成活的。所有其他死的单元在下一代仍是死的。
- 所有的出生和死亡都刚好在同一时间发生，因此正在死亡的单元有助于另一个单元的出生，但它不能通过减少阻塞而组织其他单元的死亡；正在出生的单元也不能保护或杀死上一代中活着的单元。
以上是我从我第一次看到The Game of Life的书——Data structures and Program Design In C++——里面节选出来的，除了括号里面的字，因为我比较喜欢那样的称呼^_^。
第（6）点可能有点怪怪的，举个例子说。假如下面的©代表一个alive的cell，◎、①代表一个dead的cell，那么对于以下这样的情况，◎的位置的cell因为刚好有3个neighbors，将会变活。但这不会影响到旁边的标记为①的cell的生死，①位置的cell只有2个neighbors，没办法继续存活。
◎①
©©©
就是这么简单的6条规则（我承认我的那本书上写得有点长气），但这么简单的几条规则确可以变化出相当复杂的过程。不同的初始宇宙配置（就是第一代宇宙的模样），演变下去规模可以变得十分庞大复杂，也可能慢慢的变得稳定，有的甚至灭绝（全部细胞都挂了――b）。
在The Game of Life发明后不久，Martin Gardner就在Scientific American的专栏里面对它进行了讨论，很多人为之着迷。
没有理由的感叹一下，The Game of Life，会不会就是我们的现实生活的一个写照呢？在我们活着的这样的复杂不堪的世界里面，说不定只有几条十分简单的规则在不停运转着。
只是我们还没有发现（或者说没完全发现）The Game of Our Life的规则而已。
当上帝的助手——实现The Game of Life
Conway给我们定下了6条规则而把宇宙交给了我们。我第一次实现The Game of Life（好长……后面简称tgol好了）是在C++上，大约是2年前的事情了吧。最近无意中在emacs里面再次发现了它的身影，又正逢我在学习python，正好拿来练习练习。
于是好几个版本的tgol（在我编写的时候，tgol被我称做Life Game）诞生了，限界不限界的都有，到今天成功进化到了1.3.2版（其实我不太会定版本号――b，下载的链接可以在文章末尾找到），学到的还是不少的。
* 有界还是无界？
在Conway设定的tgol里面的universe本来是无界的。由于边界的原因，有界的结果跟无界的有时是大相径庭的。主要原因在于有界的宇宙，细胞一旦到边界了就无法继续发展，因而边界外也不会产生活细胞对边界内的universe进行干涉。
绝对不会是最有效，但绝对是最简单的实现有界tgol的算法就是一个矩形数组（在python里面就是list的嵌套），然后从最开始遍历到最后。对于边界的cell可以加入额外的监视哨消除特殊性，然后就没什么好说的了。
而对于无界tgol，用这样的算法实现会相对复杂一点。我们或许可以申请一个相当大的数组去表达我们的宇宙，但我们并没办法阻止细胞们的增长，再大的数组也可能容不下我们的细胞。而且随着数组的增长，遍历整个数组的时间会变得越来越长。第一版的tgol就是用这样的算法实现的，结果前100多200代耗时还忍受得了，200代之后就变得蜗牛一样了。
这似乎是个解决的办法：随时缩少数组的规模。这对于某些增大了然后又缩小的细胞社会（society）似乎是有效的。缩少数组的规模并非意味限制宇宙的大小，很简单的例子是，用一个100×100的数组去表示一个只有1个细胞的宇宙，很明显是小题大做，一个3×3的数组就足够了，10000次遍历和9次遍历差别可是很大的哦^_^。
然而事实上这种做法没什么效果，首先是，细胞社会不会一直缩小下去，很可能过两三代以后又开始变大了，虽然确实缩小了遍历次数，然而对于整个运行来说，显得苍白无力；其次是，有些society会一直膨胀不缩小，在我发布的1.3.2版里面的”five block”就是很典型的例子。
对于用数组存储universe的这条路径，我还构思过一个方法，然而没有用来实现：只对需要计算的cell进行计算。所谓的“需要计算的cell”，就是存在变活或变死可能性的cell。很明显一个没有neighbor的dead cell是不可能变活的，存在变化的只有仍然alive的cell以及它们的邻居。为了用这种方法，必须对这些需要计算的细胞进行额外的记录（不然还是得从头遍历一次来确认）。在一次计算结束后，剔除无法存活的细胞，对剩下的细胞继续进行计算，这样遍历的次数就会大大的降低了。
这跟稀疏矩阵十分相似。
* 三元组还是十字链表？
作为稀疏矩阵的两种常用实现方法，我认为三元组比较直观，十字链表比较灵活。
而应用在tgol又是怎样的情况呢？
为了索引某个位置的细胞是否存活，查找是必须的。在理想的情况里面，对于三元组，一次索引就意味着平均要花上０.5(number_of_cells+1)次的比较。相比起来，十字链表需要的次数要少一些：假设细胞们很整齐的排成m×n，那么要索引到一个细胞平均起来需要0.5(m+n+2)次（行平均次数＋列平均次数）比较。如果进一步假设m=n=sqrt(number_of_cells)，平均就要花上(sqrt(number_of_cells)+1)次的比较。
而要决定一个细胞存亡的命运，必须进行9次索引操作（8次用于邻居，1次用于自身），合起来一共是9×number_of_cells次索引。
看得出用十字链表效率上是比较高的，主要原因应该是出于十字链表本身可按行按列遍历。当然换来的是空间上的损耗，不过从性能提升的角度来看，那些损耗是“物超所值”的。
* Cross List? Hash table?
哈希表的使用完全归功于我的tgol启蒙书——还是开头我说的那本。实际上，v1.3.2的实现就是用哈希表而不是十字链表实现的。事实上我没用十字链表实现过tgol，因为在我想到十字链表实现法之后的不久我就再次拜读了启蒙书去了，并发现hash table的效率似乎更优于cross list。
Hash table以其O(1)的时间复杂度著名，主要原因在于它在实现上还是一个数组，要访问hash table里面的元素就跟访问数组一样——直接定位，即使有冲突的问题存在，但无论是顺序hash table还是链式hash table都有一个有效的解决方法（我个人更欣赏链式的）。
那么选择hash table的原因就很明显了：O(1)的时间复杂度。这意味着，对于每个细胞，很多情况下1次查找就可以索引出结果了。尽管hash table中的冲突现象难以消除，但对于一个合理大小的hash table配合一个合理的hash函数来说，冲突是比较少的。
这样效率上的优势就很明显了，hash table的实现，可以把索引需要的查找次数控制在次低（仅仅从指定cell的查找次数方面评价，正牌的数组绝对是大哥，随机索引一次完成。而对于有一定规模的数据，hash table的冲突是很难避免的，而解决冲突必定会引入更多次的索引）。
---
回头一看发现自己已经写了2千多字了……希望自己写的不是些无用的废话吧。
刚刚回看自己的tgol代码，发现有些小细节还可以改进，代码就先不公开贴上来了，等我再写好点先……由于1.3.2里面用到了windows的API的关系，拙作暂时只能运行在windows系统上，可以在这里下载用py2exe发布好的win32-binary。1.3.2还只是windows console下的字符版，以后有时间，或许会利用python再写一个gui版吧。
感谢Conway的The Game of Life给我带来的欢乐。
另一个开篇
我的blog搬家了～
不过其实呢，Blogger.com是我第一个选择的blog service provider，但是那时候帐号注册好了，blogger送给我的http://xthex.blogspot.com却没办法浏览，偏偏我知道的用来浏览自己blog的url就只有这个。
……换句话说，我发表的新post浏览不了……
今天看到dtboy给我的免费bsp list（thx dtboy again哦^_^），“blogger”这个名字又跳进眼里，抱着再看看的心理试了试，结果：pass。没想太久，决定搬家blogger了！（因为blogger确实很吸引我啊，理由：没有。爱是不需要理由的！）
至于blogcn上的文章，打算慢慢移转到这里面。
听说，blogger的自由度是比较高的，说不定能实现我的梦想啊（是什么暂时保密～）！想到以后就不由得高兴起来了。
不过现实是很残酷的……复习的任务马上给我当头一棒，呜呜……
为了新的blog，我要加油！
写在第一次实习之后
现在有点觉得这标题是否合适。一开始确实想写点东的西的纪念纪念，打开blog以后就完全没回事了－－b
（一）因为想到这个blog并不那么合心意。
我用的web browser是firefox v1.5。之前写那篇Happy Pythoning的时候（现在对是pythoning还是pythonning 不太肯定了……哪位知道的告诉我一下哦），blogcn似乎是跟firefox闹了矛盾，没办法正常发文，最后不得不换成IE了，觉得自己受了很大委屈， 为什么不能用我喜欢的浏览器写blog啊，抗议！本来以为今晚也要那么郁闷，打算“找过个新的吧”的时候，结果发现两个已经握手言和。呵，这样，我还是继 续在blogcn里面胡诌好了。
（二）既然想到了换新blog……
当然就想找个能兼容firefox的了！不过用什么关键字好呢～这个问题却犯难了，不管了先搜搜以后发现，firefox 2.0 beta related的条目多了很多，我记得我之前搜的时候还很少的啊……不过那好像也是咸丰年前做的事情了，大概是我太火星了吧～写完这咚咚，一定要download一个回来试试！
（三）继续由这个blog想起……
我曾经看过csdn的blog系统，当时很醒目的一条消息写着csdn一个支持从word直接发布blog的插件发布了。当时马上想到，blogcn是不是也搞个这样的插件，让我这等新进blog户爽一下呢～今天在搜索新blog的时候又发现了类似的东西。嗯，在网络时代赶潮流，插件似乎是个不错的着手点啊。
（四）还是这个blog。因为我看见了……
一条消息！兴奋啊，有人留言给我了。感谢dtboy～虽然他似乎是在埋怨我不去更新我的blog了^_^
（五）是时候说点别的了吧，别说这个blog了。
虽然想那么做，但结果我还是喜欢说blog！话说在“Happy Python(n?)ing”之后，自己就想在有空的时候找个什么subject来练习练习手艺吧。刚刚好django的tutorial上面提及到一个简单的blog系统，不如就用这个做练习吧！不写不知道，着手了才发现，这东西想随意写写还真不容易，写着写着就发现了新问题了，然后之前写的就又修改修改，修改完以后又发现问题了，继续修改，继续发现不足……啊，简直是恶梦。果然做个比较系统的分析是有必要的，不过现在自己能花在这上面的时间比较零星啊，还是只能随便一下了。
回头一看自己全在说blog。为了不用换标题……
果然实践是真理啊，边看具体的生产工具边回忆起自己听到的讲解，知识更容易进脑子了。不过正如那位做讲解的老师说的，我们今天在材料所做的非生产实习也非参观实习，只能算“参观指导”了。期待一下下星期到广州各公司做的参观实习好了。
不过虽说只是“参观指导”，得到的东西还是蛮多的。最起码，可以明白到自己学的化学应用到生产上是什么样子的。但是同时也发现……自己学到的东西很多都不记得了！呜呜。
Happy Pythoning
准确地说是Python & Django ing，不过这样做标题明显没那么好看^_^。
Python这个词已经听过不少次了，也知道它能用来写Web Application，不过一直没想去试。最近在家能做的事情实在单调又无聊，搞了过来试试，发现十分有趣，不管是Python自身，还是用Python来写Web App。Django上的tutorial一天就被我吃掉了，不过还没来得及消化- -b。
没有键盘的日子
键盘坏了也不是一两天的事情了，不过就算到了现在这样“非得用桌面键盘打字”的时候，我都还是懒得去花时间买过一个新的，因为确确实实是废钱又废时的事情：买回来用不到几天就不用了，因为马上就要返校，学校还有键盘在；还得劳驾父亲大人载我出去买，因为家里除了脚力和机动车就没其他交通工具了，我自己又没有驾照……
结果就拖一天是一天，从妹妹里抢过好的键盘来活得自在；然而今天开始妹妹就要忙着高考补录的事，好生活也得到尽头了，只能把键盘归还，慢慢用鼠标点字了。不过也好，不然blog大概还要继续荒凉一个星期。
话又说回来，我以前还真没试过坏键盘，只试过用键盘模拟鼠标，用鼠标模拟键盘，还算是新鲜的体验吧！
Tsubasa
Far in the light, I can see it
in every scene of the night
A tiny feather of love
I gotta go
Destiny never finds the way for me, my love
Even in the night I see your face, in the dark
so I never lose my way to you
I never close my heart
the light is always there
Time goes by, we can never stay the same
Now we've come so far from love memory
Though yours smile has gone, we will never be apart
in our hearts we are one, for love melody
The future arrives with your love
Willing to go to the place
where you never need to cry
I'll take you there
Willing to find an answer
in all the winding road we have come through
In the heat of summer, cold of winter, I'm here
so you never lose your way to me
Never close your heart
your light is always here
Times goes by, we can never stay the same
in the shades of hope, in love memory
Though your smile has gone, we will never be apart
in our hearts we can hear the love melody
The future sill shines, close to you