在中欧上课所作――吴敬琏教授的作业
竟然欠债还这么有道理！
星期三, 一月 28, 2009
星期日, 一月 25, 2009
年三十
年三十还是很特殊的。稍微记点什么。
晚上稍微喝了点米酒，醉醺醺的。先玩了几把魔兽。又学了两个小时的SWIG。学的进度是很慢，学一会，玩一会。但还是把两个例子走了一遍，有收获的。是为记。
凌晨1:19，外面的烟花声音逐渐小了。没什么特别的心情，和平常一样，不同的是今晚收到特别多的拜年短信（虽然内容看来看去没什么新意，我回短信把手机都回没电了）。这么多人过年还记得你，小心情就像喝了米酒一样，醉醺醺的。
祝我的亲人朋友们新年快乐，学习进步！
晚上稍微喝了点米酒，醉醺醺的。先玩了几把魔兽。又学了两个小时的SWIG。学的进度是很慢，学一会，玩一会。但还是把两个例子走了一遍，有收获的。是为记。
凌晨1:19，外面的烟花声音逐渐小了。没什么特别的心情，和平常一样，不同的是今晚收到特别多的拜年短信（虽然内容看来看去没什么新意，我回短信把手机都回没电了）。这么多人过年还记得你，小心情就像喝了米酒一样，醉醺醺的。
祝我的亲人朋友们新年快乐，学习进步！
星期四, 一月 22, 2009
医学和计算机体系结构
老牛是学医的，他说医院里面三大诊断手段分别是X光、CT和核磁共振[link]。
我觉得跟计算机体系结构里面的monitoring很像，通过仪器来监视系统的运行情况，得到系统某个特征的呈现。
X光、CT和核磁共振的区别，在于检测的手段不同，得到的图像侧重点不同。
计算机的不同monitoring的方式也是如此，最后得到的数据侧重点有所不同。
这是一点。
另外一点。研究计算机体系结构还有两种方法，模拟和数学建模。
模拟是不是就相当于用小白鼠做实验。数学建模就相当于是在分析药物的各种成分。
软件模拟<-->小白鼠
FPGA模拟<-->临床实验
真正的系统<-->成品药
我觉得跟计算机体系结构里面的monitoring很像，通过仪器来监视系统的运行情况，得到系统某个特征的呈现。
X光、CT和核磁共振的区别，在于检测的手段不同，得到的图像侧重点不同。
计算机的不同monitoring的方式也是如此，最后得到的数据侧重点有所不同。
这是一点。
另外一点。研究计算机体系结构还有两种方法，模拟和数学建模。
模拟是不是就相当于用小白鼠做实验。数学建模就相当于是在分析药物的各种成分。
软件模拟<-->小白鼠
FPGA模拟<-->临床实验
真正的系统<-->成品药
星期三, 一月 21, 2009
[People] Godel
A legendary man. And this is a cool present. Haha~
http://en.wikipedia.org/wiki/Kurt_G%C3%B6del
In 1951, Gödel demonstrated the existence of paradoxical solutions to Albert Einstein's field equations in general relativity. He gave this elaboration to Einstein as a present for his 70th birthday.[8] These "rotating universes" would allow time travel and caused Einstein to have doubts about his own theory. His solutions are known as the Gödel metric.
Link:http://en.wikipedia.org/wiki/Kurt_G%C3%B6del
星期二, 一月 20, 2009
Of taking advice
When you ask for advice, ask the masters. Here is a list of a few advices collected from the successful pioneer researchers.
Links:
[1]Dijkstra's advice to a young scientist, http://lucis.net/archives/2004/03/02/dijkstras-advice-to-a-young-scientist/
[2]You and Your Research by Richard Hamming, http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
[2]:
There's another trait on the side which I want to talk about; that trait is ambiguity. It took me a while to discover its importance. Most people like to believe something is or is not true.Great scientists tolerate ambiguity very well. They believe the theory enough to go ahead; they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory. If you believe too much you'll never notice the flaws; if you doubt too much you won't get started. It requires a lovely balance.
[1]
● Raise your standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this because it is the only way of discovering how that boundary should be moved forward.
● Before embarking on an ambitious project, try to kill it.
There's another trait on the side which I want to talk about; that trait is ambiguity. It took me a while to discover its importance. Most people like to believe something is or is not true.Great scientists tolerate ambiguity very well. They believe the theory enough to go ahead; they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory. If you believe too much you'll never notice the flaws; if you doubt too much you won't get started. It requires a lovely balance.
[1]
● Raise your standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this because it is the only way of discovering how that boundary should be moved forward.
● Before embarking on an ambitious project, try to kill it.
In Dijkstra's advice, you see this ambiguity metioned by Hamming. Your need to balance it. When setting up a plan, you need to strive for a balance on your own based on your desire, talent, and timeline.
Links:
[1]Dijkstra's advice to a young scientist, http://lucis.net/archives/2004/03/02/dijkstras-advice-to-a-young-scientist/
[2]You and Your Research by Richard Hamming, http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
最近IEM的战报
看了IEM TED打Moon， Sky打Grubby的几场战报。发现中国的电子竞技真的很强了现在。
而且是质量和数量都是全球第一了。
所以看一个事物要看他的发展趋势。
几年前老是看他们外国人表演。现在那些不是一流水平的国外选手都不知道名字了。
希望我们的计算机界也能如此。
这个他们有一个积累。但是到了在同一个规则，只比谁的努力程度的时候，中国这么多勤奋和聪明的人，绝对是应该引领方向。
而且是质量和数量都是全球第一了。
所以看一个事物要看他的发展趋势。
几年前老是看他们外国人表演。现在那些不是一流水平的国外选手都不知道名字了。
希望我们的计算机界也能如此。
这个他们有一个积累。但是到了在同一个规则，只比谁的努力程度的时候，中国这么多勤奋和聪明的人，绝对是应该引领方向。
星期日, 一月 18, 2009
星期六, 一月 17, 2009
[Photos]"Life" magazine hosted on google
http://images.google.com/hosted/life
Google上的旧《LIFE》照片。
具体介绍见这里：http://genmicha.cn/life-photo-archive-hosted-by-google.htm
以前的天安门？
Link:
http://images.google.com/hosted/life/l?imgurl=84a31c77993291a7&q=beijing%20source:life&prev=/images%3Fq%3Dbeijing%2Bsource:life%26start%3D40%26ndsp%3D20%26hl%3Den%26safe%3Doff%26sa%3DN
Google上的旧《LIFE》照片。
具体介绍见这里：http://genmicha.cn/life-photo-archive-hosted-by-google.htm
以前的天安门？
| © Time Inc. | For personal non-commercial use only | View full size |
Link:
http://images.google.com/hosted/life/l?imgurl=84a31c77993291a7&q=beijing%20source:life&prev=/images%3Fq%3Dbeijing%2Bsource:life%26start%3D40%26ndsp%3D20%26hl%3Den%26safe%3Doff%26sa%3DN
星期五, 一月 16, 2009
Reading: Debugging—The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
[笔记]如何读一本书
最近快速读了三四本书。小有收获。简记如下。
读书方式的改变：
1、从头读到尾
最正常的读。从小学开始的读法。
2、结合目录从头读到尾（或者在读的时候建立自己的提纲）
大学毕业还是不会读，后来试着读完每段一句话回顾一下每段的大意。
初中就让归纳每段的段落大意，当时就当家庭作业做了，不知道归纳段落大意干什么用。
（不学计算机的飘过~）其实就是建立树的索引。方便在理解全文的时候索引。
3、结合问题结合目录从头读到尾
读一本书，
4、结合问题结合目录从尾读到头
最近就是这么读。（其实你读我的这篇blog也可以这么读，这里才讲到重点。）
一本书的最后，会举一个实际例子，把前面讲到的所有知识都用上。到了这里，才真正的动手。前面讲的是skills，是分解后的各个部分，要到最后串起来才成为这本书的整体。比如：
1)赵炯的《Linux 内核完全注释》。我前后读了有四五次，第一次、第二次、第三次都是从头开始读。可能第一次读了第一章，放弃；第二次读了第一章和第二章，放弃；第三次读了第一二三章，放弃。好像是从第三次开始建立实验环境来试。这才有对实际系统的理解。后来第四次第五次就还好了，基本是带着问题去读。
2)Debugging with gdb。从1读到29章顺序读会死人的，读完都是几年以后的事情了。而我最近学到的好的trick，是在23. GDB Text User Interface，等你顺序读到这里在学到这个技巧，那就晚啦。
3)Code Reading: The Open Source Perspective。也是读了三四遍，不过还好，是挑着目录读的。但还是没有直接跳到最后一章（Chapter 11. A Complete Example）读。读完发现这个例子是在几千行代码的级别插入一个新的函数。唉~这个对于一般工程是够了，我现在手头的工程如果只用这些技巧可能不够啊，何况又是并行。不过还是学到一些。没读之前是菜鸟，读了至少不是菜鸟了。
4)最近又要debugging。读《Debugging―The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems》，唉，以前又是顺序读，读半天不知道他要干什么，或者只读到了局部，看看他Chapter 12: All the Rules in One Story讲什么吧。回头再写读后感。
---
另外，关于搜参考资料：
1、在书中搜关键字，看书的参考文献（好的书的reference做得很好）
2、搜wikipedia
3、搜各个大学
4、订阅IBM developworks，还有一些水平好的程序员的blog，完了要找的时候到google reader搜。
注1：怎么觉得跟读代码一样啊。
注2：小规模的顺序读，中规模的建立树结构，大规模的在树结构上再串一条主线。
读书方式的改变：
1、从头读到尾
最正常的读。从小学开始的读法。
2、结合目录从头读到尾（或者在读的时候建立自己的提纲）
大学毕业还是不会读，后来试着读完每段一句话回顾一下每段的大意。
初中就让归纳每段的段落大意，当时就当家庭作业做了，不知道归纳段落大意干什么用。
（不学计算机的飘过~）其实就是建立树的索引。方便在理解全文的时候索引。
3、结合问题结合目录从头读到尾
读一本书，
4、结合问题结合目录从尾读到头
最近就是这么读。（其实你读我的这篇blog也可以这么读，这里才讲到重点。）
一本书的最后，会举一个实际例子，把前面讲到的所有知识都用上。到了这里，才真正的动手。前面讲的是skills，是分解后的各个部分，要到最后串起来才成为这本书的整体。比如：
1)赵炯的《Linux 内核完全注释》。我前后读了有四五次，第一次、第二次、第三次都是从头开始读。可能第一次读了第一章，放弃；第二次读了第一章和第二章，放弃；第三次读了第一二三章，放弃。好像是从第三次开始建立实验环境来试。这才有对实际系统的理解。后来第四次第五次就还好了，基本是带着问题去读。
2)Debugging with gdb。从1读到29章顺序读会死人的，读完都是几年以后的事情了。而我最近学到的好的trick，是在23. GDB Text User Interface，等你顺序读到这里在学到这个技巧，那就晚啦。
3)Code Reading: The Open Source Perspective。也是读了三四遍，不过还好，是挑着目录读的。但还是没有直接跳到最后一章（Chapter 11. A Complete Example）读。读完发现这个例子是在几千行代码的级别插入一个新的函数。唉~这个对于一般工程是够了，我现在手头的工程如果只用这些技巧可能不够啊，何况又是并行。不过还是学到一些。没读之前是菜鸟，读了至少不是菜鸟了。
4)最近又要debugging。读《Debugging―The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems》，唉，以前又是顺序读，读半天不知道他要干什么，或者只读到了局部，看看他Chapter 12: All the Rules in One Story讲什么吧。回头再写读后感。
---
另外，关于搜参考资料：
1、在书中搜关键字，看书的参考文献（好的书的reference做得很好）
2、搜wikipedia
3、搜各个大学
4、订阅IBM developworks，还有一些水平好的程序员的blog，完了要找的时候到google reader搜。
注1：怎么觉得跟读代码一样啊。
注2：小规模的顺序读，中规模的建立树结构，大规模的在树结构上再串一条主线。
星期三, 一月 14, 2009
茶话会
昨天晚上茶话会。所有人谈今年最难忘的一件事情。其实从这一件事就可以看出每个人的境况。
学到的很多，不一一列举。说一个感受比较深的，是一个师姐说的。
师姐说她家的三个孩子都离开家出去外面闯荡，她的小妹妹懂事了能给家里买东西了，她爸爸学会了写博客，其中一篇叫《空巢家庭》。
想到自己上周因为太忙没有给家打电话，这周三老爸打电话来，虽然嘴上没说，但我知道他是很想我了。尤其是去年弟弟也去上大学后，家里就冷清了。
本来还因为实验室忙，打算过年少回去几天。现在确实是想家了。回家！
学到的很多，不一一列举。说一个感受比较深的，是一个师姐说的。
师姐说她家的三个孩子都离开家出去外面闯荡，她的小妹妹懂事了能给家里买东西了，她爸爸学会了写博客，其中一篇叫《空巢家庭》。
想到自己上周因为太忙没有给家打电话，这周三老爸打电话来，虽然嘴上没说，但我知道他是很想我了。尤其是去年弟弟也去上大学后，家里就冷清了。
本来还因为实验室忙，打算过年少回去几天。现在确实是想家了。回家！
[Quotes]关于选题
所谓构想力是限定问题的能力。
用手捧起沙子，就像捧起问题。沙子捧得太多，城堡就会承受不了压力而崩塌；捧得太少，又没有什么价值。
如果能给问题下个定义，就已经解决了60%。
其实在解决问题的过程中，最重要的就是弄清楚问题的疑难点在哪里。
――《像外行一样思考，像专家一样实践》
很少有人问自己为什么要研究这一课题，许多研究没有Motivation(动机)。
真正的聪明才智主要不是表现在找答案而是找到最值得解决的问题。
有大成就的计算机学者的本领主要是Find Problem(找问题)，而不仅仅是Find Solution(找答案)。
――《创新求索录》
用手捧起沙子，就像捧起问题。沙子捧得太多，城堡就会承受不了压力而崩塌；捧得太少，又没有什么价值。
如果能给问题下个定义，就已经解决了60%。
其实在解决问题的过程中，最重要的就是弄清楚问题的疑难点在哪里。
――《像外行一样思考，像专家一样实践》
很少有人问自己为什么要研究这一课题，许多研究没有Motivation(动机)。
真正的聪明才智主要不是表现在找答案而是找到最值得解决的问题。
有大成就的计算机学者的本领主要是Find Problem(找问题)，而不仅仅是Find Solution(找答案)。
――《创新求索录》
星期二, 一月 13, 2009
[Note]Python's Design Philosophy
Python's Design Philosophy
by Guido van Rossum- Borrow ideas from elsewhere whenever it makes sense.
- "Things should be as simple as possible, but no simpler." (Einstein)
- Do one thing well (The "UNIX philosophy").
- Don't fret too much about performance--plan to optimize later when needed.
- Don't fight the environment and go with the flow.
- Don't try for perfection because "good enough" is often just that.
- (Hence) it's okay to cut corners sometimes, especially if you can do it right later.
[CS] The history of python
- Guido van Rossum is starting a blog about the history of python. For those of you who know python, or who is going to learn python, it is the definite blog to subscribe.
星期一, 一月 12, 2009
Reading Today: Yale Patt 's ten commandments
http://users.ece.utexas.edu/~patt/Ten.commandments/
Y.P. again!
There seems to be a lot to learn from him. Even as encyclopaedic as YP, he is willing to say those three words.
Although these are advices for good teaching, I still learn a lot from them. After all, learning is self teaching.
Y.P. again!
There seems to be a lot to learn from him. Even as encyclopaedic as YP, he is willing to say those three words.
Although these are advices for good teaching, I still learn a lot from them. After all, learning is self teaching.
mark
今天看到这个超级项目：12/01/2009 18:57:26
The GEMS/M5 integration project
http://www.m5sim.org/wiki/index.php/Integrating_M5_and_GEMS
有幸见证'working' GEMS/M5的诞生。
The GEMS/M5 integration project
http://www.m5sim.org/wiki/index.php/Integrating_M5_and_GEMS
有幸见证'working' GEMS/M5的诞生。
The GEMS/M5 integration project
[edit] Sprint
We're having a coding sprint on January 13, 2009. The sprint begins at 9AM PST/11AM CST. We will begin with a phone call on Nate's conference line and use IRC throughout the day.
[edit] Goal
To get a "working" unified simulator by the end of the day.
[edit] Tasks
- Unified build environment using scons -- Arka w/ Nate and Steve supervising
- Support system call emulation mode
- Support full system mode
- atomic support, especially load locked/store conditional -- Derek
- pio support
- Deal with lack of first-class data support in Ruby
- Configuration management
- Testing infrastructure base on m5 infrastructure
- Which tests?
- What run modes to support? A fast Ruby-less or Ruby-lite mode?
- Develop detailed list of future tasks
[edit] Participants
- Nathan Binkert (All Day)
- Dan Gibson (All Day)
- David Wood (All Day, except 12:30-2pm CST)
- Derek Hower (All Day)
- Steve Reinhardt (All Day except 10-10:30 PST)
[edit] Long Term Tasks
- Ruby-side: Data in caches
- I don't see a huge need for this, but if it is forced on us, it'll be good to have a junior grad student (JGS) do it. Basically we have to revive the old DATA_BLK flag, which worked in the 'research tree' when I joined the group. I've turned it on for my own reasons in the past, discovered it was broken, and put no effort into fixing it.
- Ruby-side: Python configuration adaptation
- M5 uses a very different configuration system than Ruby, and Ruby's was based heavily on the Simics CLI. I have a hack in place, so that it is possible to change some Ruby parameters at runtime (any at compile-time), but that should be temporary -- we should switch entirely to M5's style. It will little more than a lot of grep'ping and such, but again its a good familiarization excercise. At the same time, we can prune some fat from the configuration parameters.
- Ruby-side: M5 fast/timing mode support
- Timing mode is Ruby's normal operation. Its possible that we can use 'fast' mode to warm caches (as we currently do from gzipped traces). This will require some new coding here and there, as well as testing.
- Ruby-side: Atomic support
- This may be important for us in the long run. We'll do some kind of horrible nasty hack in the sprint, but we'll want something flexible, generic, and elegant in the long run. We'll need a clever JGS to make that happen. This will actually be quite challenging to integrate into existing protocols, as we need something like an M-locked state to really get the timing right. At the same time, we might also implement true write merging (read-merge-write timing), as an option (the other option is subblocked caches with per-subblock ECC).
- Ruby-side: Timing of uncached accesses
- Basically, we need add an 'isUncacheable' flag to network messages and modify SLICC to generate cache controllers that ignore messages with the isUncacheable flag set. That should effectively force the messages to traverse their normal miss path. As an optimization (depending on interconnect, etc.), we can add special routing capability to move straight to the memory controller and/or off-chip bridge. If we *add* some notion of an off-chip actor, that is.
- Ruby-side: Fix Directory Memory
- DirectoryMemory.C implements 'generic' directory data by allocating permanent directory state for all cache blocks in the physical memory. This is fine, except it is stored as an array of DirectoryEntry*. The size of that array is MAX_ADDRESS / CACHE_LINE_SIZE_BYTES. That, too, is fine, except when the physical memory space isn't contigous. E.g. when addresses start at 0, run to 0x0ff, then resume at 0x100000 through 0x1000ff. It happens -- for instance when we simulate really large machines with huge complex backplanes. It /can/ happen in M5, too. Ruby also seems to leak memory because of this... even though its not really a leak. The solution is to move the whole data structure from array-based to some kind of balanced tree. Its been on the list of things to do for a long long time.
星期日, 一月 11, 2009
Some reviews
要隔一段时间review一次
re:12月11日
Knuth啊Knuth啊，你还是Yale Patt的hero啊
踢踏舞跳完了，有始有终。元旦晚会。记下省得忘。
re:12月24日
大师Patterson
但是另外一个大师Yale Patt不把大师Patterson当作大师
re:12月11日
Knuth啊Knuth啊，你还是Yale Patt的hero啊
踢踏舞跳完了，有始有终。元旦晚会。记下省得忘。
re:12月24日
大师Patterson
但是另外一个大师Yale Patt不把大师Patterson当作大师
很晚了
想起Yale Patt说他是vampire
他的视频，关键的说到技术的没怎么听，一些小故事倒是记得很清楚。
今天一口气写了一堆blog。记得前几天有这么个感觉：牛人都没有时间写blog，他们写paper的速度比写blog还快。
从今天调研Dave和William的结果看确实如此，一个20多篇ISCA和一个30多篇MICRO。
第三，写长的文章好写，想到哪写到哪。所以，这基本就是流水账了。如果你不幸看了我写的流水账，就在我blog里面灌灌水吧。
他的视频，关键的说到技术的没怎么听，一些小故事倒是记得很清楚。
今天一口气写了一堆blog。记得前几天有这么个感觉：牛人都没有时间写blog，他们写paper的速度比写blog还快。
从今天调研Dave和William的结果看确实如此，一个20多篇ISCA和一个30多篇MICRO。
第三，写长的文章好写，想到哪写到哪。所以，这基本就是流水账了。如果你不幸看了我写的流水账，就在我blog里面灌灌水吧。
Reading Today: 知其所以然地学习（以算法学习为例)
知其所以然地学习（以算法学习为例）by 刘未鹏
http://blog.csdn.net/pongba/archive/2008/07/07/2622713.aspx
关于答案&做法到底是怎么来的，从问题到答案之间经历了怎样的思维过程。却鲜有书能够很好的阐释。就我有限的阅 （算法）书经验，除了波利亚的《怎样解题》还算合格之外（也并非最理想），其它的（包括有名的《算法导论》、《如何解题：现代启发式方法》、 《Algorithms》、《编程珠玑》，甚至TAOCP――公平地说由于高老大对算法领域历史了解得非常通透，所以许多地方能够从原始脉络来讲述一个问 题，譬如令人印象深刻的从竞赛树到堆的讲解就寥寥一页纸道出了堆这个数据结构的本质来，而像刚才列的几本有名的书却都没有做到），在思维的讲述上都算不上 合格（当然不是说这些书没有价值，作为知识性的参考书籍，它们将知识整理出系统结构，极大的便利了知识的掌握，就像《什么是数学》所做的工作一样），为什么我这么说呢，因为我发现每每需要寻找对一个算法的解释的时候，翻开这些书，总是直接就看到关于算法逻辑的描述，却看不到整个算法的诞生过程背后的思想。
评：这么说吧，TAOCP讲出了approach，其他的书都是skill。
那到底什么样的才算是授人以渔的呢？波利亚的《如何解题》绝对算是一本，他的《数学的发现》也值得一看。具体到算法书，那就不是光看text book就足够的了，为了深入理解一个算法的来龙去脉前因后果，从一个算法中领悟尽量深刻的东西，则需要做到三件事情：
寻找该算法的原始出处：TAOCP作为一个资料库是绝对优秀的，基础的算法只 要你能想到的，几乎都可以在上面找到原始出处。查到原始出处之后（譬如一篇paper），就可以去网上搜来看了。因为最初的作者往往对一个方案的诞生过程 最为了解。比如经典数据结构中的红黑树是出了名的令人费解的结构之一，但它的作者Sedgewick一张PPT，给你讲得通通透透，比算法导论上的讲法强上数倍。
原始的出处其实也未必就都推心置腹地和你讲得那么到位：……怎么办？可以再去网上找找，牛人讲得未必比经典教材上的差。那倘若实在找不出好的介绍呢，就只能自己揣摩了。揣摩的重要性，是怎么说都不为过的。揣摩的一些指导性的问题有：……问题的本质是什么？这个做法的本质又是什么？……
不仅学习别人的思路，整理自己的思路也是极其重要的：详见《跟波利亚学解题》的"4. 一个好习惯"和"7. 总结的意义"。
评：
1、找原出处，引Emerson的话：first quote是要找到原话。
2、找牛人。找不到，自己问问题。
3、学习，整理。Resharp the shaw.
http://blog.csdn.net/pongba/archive/2008/07/07/2622713.aspx
关于答案&做法到底是怎么来的，从问题到答案之间经历了怎样的思维过程。却鲜有书能够很好的阐释。就我有限的阅 （算法）书经验，除了波利亚的《怎样解题》还算合格之外（也并非最理想），其它的（包括有名的《算法导论》、《如何解题：现代启发式方法》、 《Algorithms》、《编程珠玑》，甚至TAOCP――公平地说由于高老大对算法领域历史了解得非常通透，所以许多地方能够从原始脉络来讲述一个问 题，譬如令人印象深刻的从竞赛树到堆的讲解就寥寥一页纸道出了堆这个数据结构的本质来，而像刚才列的几本有名的书却都没有做到），在思维的讲述上都算不上 合格（当然不是说这些书没有价值，作为知识性的参考书籍，它们将知识整理出系统结构，极大的便利了知识的掌握，就像《什么是数学》所做的工作一样），为什么我这么说呢，因为我发现每每需要寻找对一个算法的解释的时候，翻开这些书，总是直接就看到关于算法逻辑的描述，却看不到整个算法的诞生过程背后的思想。
评：这么说吧，TAOCP讲出了approach，其他的书都是skill。
那到底什么样的才算是授人以渔的呢？波利亚的《如何解题》绝对算是一本，他的《数学的发现》也值得一看。具体到算法书，那就不是光看text book就足够的了，为了深入理解一个算法的来龙去脉前因后果，从一个算法中领悟尽量深刻的东西，则需要做到三件事情：
寻找该算法的原始出处：TAOCP作为一个资料库是绝对优秀的，基础的算法只 要你能想到的，几乎都可以在上面找到原始出处。查到原始出处之后（譬如一篇paper），就可以去网上搜来看了。因为最初的作者往往对一个方案的诞生过程 最为了解。比如经典数据结构中的红黑树是出了名的令人费解的结构之一，但它的作者Sedgewick一张PPT，给你讲得通通透透，比算法导论上的讲法强上数倍。
原始的出处其实也未必就都推心置腹地和你讲得那么到位：……怎么办？可以再去网上找找，牛人讲得未必比经典教材上的差。那倘若实在找不出好的介绍呢，就只能自己揣摩了。揣摩的重要性，是怎么说都不为过的。揣摩的一些指导性的问题有：……问题的本质是什么？这个做法的本质又是什么？……
不仅学习别人的思路，整理自己的思路也是极其重要的：详见《跟波利亚学解题》的"4. 一个好习惯"和"7. 总结的意义"。
评：
1、找原出处，引Emerson的话：first quote是要找到原话。
2、找牛人。找不到，自己问问题。
3、学习，整理。Resharp the shaw.
Video Today:Microprocessor Performance, Phase 2
Microprocessor Performance, Phase 2:
Harness the Transformation Hierarchy
by Yale Patt, The University of Texas at Austin
very Micky Mouse question
My hero in this ... is Donald Knuth.
How does hardware drive architecture?
-Everything should drive everything else
其中YP讲到电脑比起人脑要复杂10^5次，但是在智能问题上，远不如人脑。
问题是，我们有没有很好地使用起电子器件。
图灵机的意义在于将可计算问题简单地实现。
现在并行遇到的问题是在于找到简单的模型。
也许，不仅仅是简单的并行。
我有一种感觉，根据概率可以设计更好的机器。
Harness the Transformation Hierarchy
by Yale Patt, The University of Texas at Austin
very Micky Mouse question
My hero in this ... is Donald Knuth.
How does hardware drive architecture?
-Everything should drive everything else
其中YP讲到电脑比起人脑要复杂10^5次，但是在智能问题上，远不如人脑。
问题是，我们有没有很好地使用起电子器件。
图灵机的意义在于将可计算问题简单地实现。
现在并行遇到的问题是在于找到简单的模型。
也许，不仅仅是简单的并行。
我有一种感觉，根据概率可以设计更好的机器。
Reading Today: 为什么几种简单的语句就可以写出所有的程序
这个问题以前想过，一直没有答案。
讲C语言的老师也没有提。
今天在这里找到了答案：
https://groups.google.com/group/pongba/browse_thread/thread/e209be4a33312f7b#
学习了。
讲C语言的老师也没有提。
今天在这里找到了答案：
https://groups.google.com/group/pongba/browse_thread/thread/e209be4a33312f7b#
我们平常用的C，C++，JAVA语句由sequence, selection和iteration三种结构组成，
他们可以构成Chomsky 2型语言（上下文无关语言），
而2型语言又是0型语言的一个子集（递归可枚举语言），
而0型语言可以完整表示所有确定性图灵机可计算语句，
而图灵机又是建立在Kurt Godel的证明上的。
学习了。
Reading Today: The Cathedral and the Bazaar
1. Every good work of software starts by scratching a
developer's personal itch.
2. Good programmers know what to write. Great ones know
what to rewrite (and reuse).
Linus Torvalds, for example, didn't actually try to write
Linux from scratch. Instead, he started by reusing code and ideas
from Minix, a tiny Unix-like operating system for PC clones.
Eventually all the Minix code went away or was completely
rewritten—but while it was there, it provided scaffolding for the
infant that would eventually become Linux.
3. ``Plan to throw one away; you will, anyhow.'' (Fred
Brooks, The Mythical Man-Month, Chapter 11)
Or, to put it another way, you often don't really understand
the problem until after the first time you implement a solution.
The second time, maybe you know enough to do it right. So if you
want to get it right, be ready to start over at least once [JB].
4. If you have the right attitude, interesting problems will
find you.
5. When you lose interest in a program, your last duty to it is
to hand it off to a competent successor.
12. Often, the most striking and innovative solutions come
from realizing that your concept of the problem was wrong.
When you hit a wall in development—when you find
yourself hard put to think past the next patch—it's often time to
ask not whether you've got the right answer, but whether you're
asking the right question. Perhaps the problem needs to be
reframed.
Link:
http://www.linuxsir.org/bbs/showthread.php?p=1707966
developer's personal itch.
2. Good programmers know what to write. Great ones know
what to rewrite (and reuse).
Linus Torvalds, for example, didn't actually try to write
Linux from scratch. Instead, he started by reusing code and ideas
from Minix, a tiny Unix-like operating system for PC clones.
Eventually all the Minix code went away or was completely
rewritten—but while it was there, it provided scaffolding for the
infant that would eventually become Linux.
3. ``Plan to throw one away; you will, anyhow.'' (Fred
Brooks, The Mythical Man-Month, Chapter 11)
Or, to put it another way, you often don't really understand
the problem until after the first time you implement a solution.
The second time, maybe you know enough to do it right. So if you
want to get it right, be ready to start over at least once [JB].
4. If you have the right attitude, interesting problems will
find you.
5. When you lose interest in a program, your last duty to it is
to hand it off to a competent successor.
12. Often, the most striking and innovative solutions come
from realizing that your concept of the problem was wrong.
When you hit a wall in development—when you find
yourself hard put to think past the next patch—it's often time to
ask not whether you've got the right answer, but whether you're
asking the right question. Perhaps the problem needs to be
reframed.
Link:
http://www.linuxsir.org/bbs/showthread.php?p=1707966
星期六, 一月 10, 2009
Parallelism
Video Today:
The Teaching Company: Building Great Sentences: Exploring the Writer's Craft
What makes Dickens's writing memorable is its
balanced form
or, extended parallelism
Just for fun. Parallelism is everywhere.
The Teaching Company: Building Great Sentences: Exploring the Writer's Craft
What makes Dickens's writing memorable is its
balanced form
or, extended parallelism
Just for fun. Parallelism is everywhere.
星期五, 一月 09, 2009
札记
看到很多paper开头都写类似It's time for a change.的句子。
哈哈。
There is always time for a change.
The question is whether you can find the right change.
哈哈。
There is always time for a change.
The question is whether you can find the right change.
星期三, 一月 07, 2009
Re: Today
把最主要的一点给忘了：
这是第三天学滑板。从实验室直接滑回了寝室。
哈哈。我也是刷过街的男人了！
――不过，为什么在人行道上走的人速度都比我快呢？!
不着急不着急。天天滑，速度不是问题。
从去年和今年的一系列learning experience得到一点，很多事，确是"为之，则难者亦易矣"。
The only limitation is yourself.
这是第三天学滑板。从实验室直接滑回了寝室。
哈哈。我也是刷过街的男人了！
――不过，为什么在人行道上走的人速度都比我快呢？!
不着急不着急。天天滑，速度不是问题。
从去年和今年的一系列learning experience得到一点，很多事，确是"为之，则难者亦易矣"。
The only limitation is yourself.
Today
贴了一张"多喝水，深呼吸！"的条子在电脑旁边。果然有效果。昨天晚上睡得很安稳。
所以导致早上起得挺早。用gdb debug，把不相关的代码注掉，使用tui模式，会发现printf全是多余的。
中午陪jy去了医院。最近感冒发烧的人很多。大家注意保暖，多喝水――深呼吸。
晚上zj来北京出差，就一起吃了个晚饭。说到他去年工资翻了一番，成了软件架构师了。主要原因是他加班加点花4个月把他们的软件重写了一遍。
所以导致早上起得挺早。用gdb debug，把不相关的代码注掉，使用tui模式，会发现printf全是多余的。
中午陪jy去了医院。最近感冒发烧的人很多。大家注意保暖，多喝水――深呼吸。
晚上zj来北京出差，就一起吃了个晚饭。说到他去年工资翻了一番，成了软件架构师了。主要原因是他加班加点花4个月把他们的软件重写了一遍。
星期二, 一月 06, 2009
Today
罗素分析人在很长一段时间干同一件事情时会感到无聊的起因是你无法通过你今天做了什么来区分昨天和今天。
从大的方面说，这段时间是有些无聊。因为都在做同一件事。而且搞不定。
从小的方面说，前两天学会了用codeviz，今天用了gdb的tui，这些都是对工具的熟悉和使用。
有句话说，与其临渊羡鱼，不如退而织网，我现在就是在织网呢。
除去专业知识方面，对于GTD的使用，也有了一个收获。
满足吧。今天过得挺好了。更何况，收到了滑板作为新年礼物。
最后，reading today：
"过早优化"是万恶之源……
http://www.xiaolai.net/index.php/archives/1850.html
还是之前提到过的笑来老师，人家不学计算机，对于计算机的道理懂得挺明白的。
还有这篇：
编程珠玑番外篇3 ― 关于程序优化的八卦
http://blog.youxu.info/2008/11/13/anecdotes-about-program-optimization/
明天看一下这篇文章：
An empirical study of FORTRAN programs
从大的方面说，这段时间是有些无聊。因为都在做同一件事。而且搞不定。
从小的方面说，前两天学会了用codeviz，今天用了gdb的tui，这些都是对工具的熟悉和使用。
有句话说，与其临渊羡鱼，不如退而织网，我现在就是在织网呢。
除去专业知识方面，对于GTD的使用，也有了一个收获。
满足吧。今天过得挺好了。更何况，收到了滑板作为新年礼物。
最后，reading today：
"过早优化"是万恶之源……
http://www.xiaolai.net/index.php/archives/1850.html
还是之前提到过的笑来老师，人家不学计算机，对于计算机的道理懂得挺明白的。
还有这篇：
编程珠玑番外篇3 ― 关于程序优化的八卦
http://blog.youxu.info/2008/11/13/anecdotes-about-program-optimization/
明天看一下这篇文章：
An empirical study of FORTRAN programs
星期一, 一月 05, 2009
星期六, 一月 03, 2009
Movie Today: 《梅兰芳》
梅大爷……送您一朵花。您不能说谢谢啊，说了马上拿回来。
着着着。
啐
风流就在这海棠花……
李凤姐，来来来，我与你插。插上这朵海棠花。
----------------------------
封建的压抑。条条框框。
而这样的情况现实当中还是能找到影子。
难怪李敖说中国人不是几十岁老，而是每个人都几千岁了。
着着着。
啐
风流就在这海棠花……
李凤姐，来来来，我与你插。插上这朵海棠花。
----------------------------
封建的压抑。条条框框。
而这样的情况现实当中还是能找到影子。
难怪李敖说中国人不是几十岁老，而是每个人都几千岁了。
订阅：
帖子 (Atom)
