After decades of programming I do not even think about these three ways to read code. I just glance at it and know what it means, and I can even glance at a whole screen of code, and all the bugs and errors jump out at me. That took an incredibly long time and quite a bit more study than is sane. To get that way, I learned these three ways of reading most any programming language:
1. Front to back.
2. Back to front.
3. Counter-clock-wise.
Try them out when you have a difficult statement to figure out. When you type the next block of your code, go over it in these ways. This one is gonna be fun.
......
I am warning you, this will be frustrating. In the business we call this "yak shaving". Yak shaving is any activity that is mind numblingly irritatingly boring and tedious that you have to do before you can do something else that's more fun. You want to create cool Python projects, but you can't do that until you setup a skeleton directory, but you can't setup a skeleton directory until you install some packages, but you can't install pacakages until you install package installers, and you can't install package installers until you figure out how your system installs software in general, and so on.
Struggle through this anyway. Consider it your trial-by-annoyance to get into the programmer club. Every programmer has to do these annoying tedious tasks before they can do something cool.
......
What I discovered after this journey of learning is that the languages did not matter, it's what you do with them. Actually, I always knew that, but I'd get distracted by the languages and forget it periodically. Now I never forget it,
and neither should you.
Which programming language you learn and use does not matter. Do not get sucked into the religion surrounding programing languages as that will only blind you to their true purpose of being your tool for doing interesting things.
Programming as an intellectual activity is the only art form that allows you to create interactive art. You can create projects that other people can play with, and you can talk to them indirectly. No other art form is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes both ways.
Programming as a profession is only moderately interesting. It can be a good job, but if you want to make about the same money and be happier, you could actually just go run a fast food joint. You are much better off using code as
your secret weapon in another profession.
People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.
Of course, all of this advice is pointless. If you liked learning to write software with this book, you should try to use it to improve your life any way you can. Go out and explore this weird wonderful new intellectual pursuit that barely anyone in the last 50 years has been able to explore. Might as well enjoy it while you can.
Finally, I will say that learning to create software changes you and makes you different. Not better or worse, just different. You may find that people treat you harshly because you can create software, maybe using words like "nerd". Maybe you will find that because you can dissect their logic that they hate arguing with you. You may even find that simply knowing how a computer works makes you annoying and weird to them.
To this I have one just piece of advice: they can go to hell. The world needs more weird people who know how things work and who love to figure it all out. When they treat you like this, just remember that this is your journey, not theirs. Being different is not a crime, and people who tell you it is are just jealous that you have picked up a skill they never in their wildest dreams could acquire.
You can code. They cannot. That is pretty damn cool.
===
***CLASS STYLE
* Your class should use “camel case” like SuperGoldFactory rather than super_gold_factory.
* Try not to do too much in your __init__ functions. It makes them harder to use.
* Your other functions should use “underscore format” so write my_awesome_hair and not myawesomehair or MyAwesomeHair.
* Be consistent in how you organize your function arguments. If your class has to deal with users, dogs, and cats, keep that order throughout unless it really doesn't make sense. If you have one function takes (dog, cat, user) and the other takes (user, cat, dog), it'll be hard to use.
* Try not to use variables that come from the module or globals. They should be fairly self-contained.
* A foolish consistency is the hobgoblin of little minds. Consistency is good, but foolishly following some idiotic mantra because everyone else does is bad style. Think for yourself.
* Always, always have class Name(object) format or else you will be in big trouble.
***CODE STYLE
* Give your code vertical space so people can read it. You will find some very bad programmers who are able to write reasonable code, but who do not add any spaces. This is bad style in any language because the human eye and brain use space and vertical alignment to scan and separate visual elements. Not having space is the same as giving your code an awesome camouflage paint job.
* If you can't read it out loud, it's probably hard to read. If you are having a problem making something easy to use, try reading it out loud. Not only does this force you to slow down and really read it, but it also helps you find difficult passages and things to change for readability.
* Try to do what other people are doing in Python until you find your own style.
* Once you find your own style, do not be a jerk about it. Working with other people's code is part of being a programmer, and other people have really bad taste. Trust me, you will probably have really bad taste too and not even realize it.
* If you find someone who writes code in a style you like, try writing something that mimics their style.
***GOOD COMMENTS
* There are programmers who will tell you that your code should be readable enough that you do not need comments. They'll then tell you in their most official sounding voice that, "Ergo you should never write comments." Those programmers are either consultants who get paid more if other people can't use their code, or incompetents who tend to never work with other people. Ignore them and write comments.
* When you write comments, describe why you are doing what you are doing. The code already says how, but why you did things the way you did is more important.
* When you write doc comments for your functions , make the comments documentation for someone who will have to use your code. You do not have to go crazy, but a nice little sentence about what someone does with that function helps a lot.
* Finally, while comments are good, too many are bad, and you have to maintain them. Keep your comments relatively short and to the point, and if you change a function, review the comment to make sure it's still correct.
November 19, 2010
some useful link for programming format
高质量C++/C编程指南
Google code: google style code (including C/C++, Javascript, and Python)
Microsoft: All-In-One Code Framework
Google code: google style code (including C/C++, Javascript, and Python)
Microsoft: All-In-One Code Framework
some advices about python coding
from 《learn python the hard way》
======
Every if-statement must have an else. If this else should never be run because it doesn't make sense, then you must use a die function in the else that prints out an error message and dies, just like we did in the last exercise. This will find many errors.
Never nest if-statements more than 2 deep and always try to do them 1 deep. This means if you put an if in an if then you should be looking to move that second if into another function.
Treat if-statements like paragraphs, where each if,elif,else grouping is like a set of sentences. Put blank lines before and after. Your boolean tests should be simple. If they are complex, move their calculations to variables earlier in your function and use a good name for the variable.
The best way to debug a program is to use print to print out the values of variables at points in the program to see where they go wrong.
Make sure parts of your programs work as you work on them. Do not write massive files of code before you try to run them. Code a little, run a little, fix a little.
When scrutinizing the code, pay attention on:
1. Functions and what they do.
2. Where each variable is first given a value.
3. Any variables with the same names in different parts of the program. These may be trouble later.
4. Any if-statements without else clauses. Are they right?
5. Any while-loops that might not end.
6. Finally, any parts of code that you can’t understand for whatever reason.
======
Every if-statement must have an else. If this else should never be run because it doesn't make sense, then you must use a die function in the else that prints out an error message and dies, just like we did in the last exercise. This will find many errors.
Never nest if-statements more than 2 deep and always try to do them 1 deep. This means if you put an if in an if then you should be looking to move that second if into another function.
Treat if-statements like paragraphs, where each if,elif,else grouping is like a set of sentences. Put blank lines before and after. Your boolean tests should be simple. If they are complex, move their calculations to variables earlier in your function and use a good name for the variable.
The best way to debug a program is to use print to print out the values of variables at points in the program to see where they go wrong.
Make sure parts of your programs work as you work on them. Do not write massive files of code before you try to run them. Code a little, run a little, fix a little.
======Every if-statement must have an else. If this else should never be run because it doesn't make sense, then you must use a die function in the else that prints out an error message and dies, just like we did in the last exercise. This will find many errors.
Never nest if-statements more than 2 deep and always try to do them 1 deep. This means if you put an if in an if then you should be looking to move that second if into another function.
Treat if-statements like paragraphs, where each if,elif,else grouping is like a set of sentences. Put blank lines before and after. Your boolean tests should be simple. If they are complex, move their calculations to variables earlier in your function and use a good name for the variable.
The best way to debug a program is to use print to print out the values of variables at points in the program to see where they go wrong.
Make sure parts of your programs work as you work on them. Do not write massive files of code before you try to run them. Code a little, run a little, fix a little.
When scrutinizing the code, pay attention on:
1. Functions and what they do.
2. Where each variable is first given a value.
3. Any variables with the same names in different parts of the program. These may be trouble later.
4. Any if-statements without else clauses. Are they right?
5. Any while-loops that might not end.
6. Finally, any parts of code that you can’t understand for whatever reason.
Top 20 Programming Lessons I've Learned in 20 Years
- Set a duration of how long you think it should take to solve a problem - C'mon, admit it! I'm just as guilty as the next programmer. I've seen programmers sit in front of a monitor for eight hours at a time trying to solve a particular problem. Set a time table for yourself of 1 hour, 30 minutes, or even 15 minutes. If you can't figure out a solution to your problem within your time frame, ask for help or research your problem on the Internet instead of trying to be super-coder.
- A language is a language is a language - Over time, once you understand how one language works, you'll notice similarities between other languages. The language you choose should provide you with a suitable "comfort" level, the ability to produce efficient (and clean) code, and, above all, allow the language to suit the project and vice-versa.
- Don't over-"design pattern" applications - Sometimes it's just easier to write a simple algorithm than it is to incorporate a singleton or facade pattern. For the most part, it even allows for cleaner, understandable code. :-)
- Always backup your code - I've experienced a complete hard drive failue and lost a lot of code when I was younger and felt horrible because of what had happened. The one time you don't back up your data may be the one time where you have a strict deadline with a client and they need it tomorrow. Source code/version control applies here as well.
- You are not the best at programming. Live with it. - I always thought that I knew so much about programming, but there is always someone out there better than you. Always. Learn from them.
- Learn to learn more - With number five explained, I've always had a magazine or book in my hand about computers or programming (ask my friends, they'll confirm). True, there is a lot of technology out there and keeping up with it is a fulltime job, but if you have a smart way of receiving your news, you'll learn about new technology every single day.
- Change is constant - Your knowledge of technology and/or programming should be similar to how you treat stocks: Diversify. Don't get too comfortable with a particular technology. If there's not enough support for that language or technology, you might as well start updating your resume now and start your training period. My general rule of thumb that has kept me going? Know at least two or three languages, so if one dies off, you have another one to fall back on while you train for a new technology.
- Support Junior - Assist and train the junior/entry-level developers on good programming guidelines and techniques. You never know...you may move up in rank and you'll feel more confident having personally trained and prepared them for their next position.
- Simplify the algorithm - Code like a fiend, but once you're done, go back through your code and optimize it. A little code improvement here and there will make support happier in the long run.
- Document your code - Whether its documenting a Web Service API or documenting a simple class, document as you go. I've been accused of over-commenting my code and that's something I'm proud of. It only takes a second to add an additional comment line for each 3 lines of code. If it's a harder technique to grasp, don't be afraid to over-comment. This is one problem most architects, backup coders, and support groups don't complain about if you've done your job right.
- Test, Test, Test - I'm a fan of Black Box Testing. When your routine is finished, your "stamp of approval" period starts. If you have a Quality Assurance department, you may be talking more to them than your project manager regarding errors in your code. If you don't test your code thoroughly, you may develop more than code. Possibly a bad reputation.
- Celebrate every success - I've met a lot of programmers who have conquered headache-style problems with a great programming technique and celebrated with a fellow programmer by doing the "shake", the high-five, or even a "happy dance." Everyone has enlightening periods in their life and even though that one happy coder asked you to come and see his extraordinary piece of code and you've seen that one piece of code over 100 times in your experiences, celebrate the success of a fellow developer for the 101-st time.
- Have Code Reviews Frequently - On projects and personally. In the company, you will always have code reviews of how well you coded something. Don't look at it as people crucifying your coding style. Think of it as constructive criticism. On the personal front, review your code and always ask, "How could I have done it better?" This will accelerate your learning and make you a better programmer.
- Reminisce about your code - There are two ways to looking at old code: "I can't believe I wrote this code" and "I can't believe I wrote this code." The first statement is often of disgust and wondering how you can improve it. You'd be surprised at how old code can be resurrected into a possible and better routine, or maybe even an entire product. The second statement is of amazement and achievement. Developers have their one or two project code achievements that they completed and had everyone standing up and taking notice. Again, based on your excellent coding ability, you could take those past routines or projects and update them into a better product or idea.
- Humor is necessary - In my 20 years of development, I have never met a programmer who hasn't had a decent sense of humor. Actually, in this industry, it's a requirement.
- Beware the know-it-all, possessive coder, and the inexperienced coder - Humble yourself when you meet these types of coders. The know-it-all tries to upstage you instead of working as a team player, the defensive coder created code that he doesn't want to share with anyone, and the inexperienced coder constantly asks for assistance every ten minutes where the finished code developed is yours, not theirs.
- No project is ever simple - I've been asked by friends, family, and associates to just "whip something up for me." To "whip" up a program or web site, it takes planning from both parties to complete something that both sides can appreciate. If someone needs a 3-page web site with Microsoft Access from the start, it winds up becoming a 15-page web site with SQL Server, a forum, and a custom CMS (Content Management System).
- Never take anything for granted - If you take on a simple project, you may think that a certain section will be easy to complete. Don't think that even for a moment. Unless you have a class, component, or piece of code already coded...and has been tested thoroughly...and is in production from an existing project, don't think it will be easy.
- Software is never finished - A fellow programmer once told me that software is never finished, it's "temporarily completed." Sound advice. If the client is still using a program you wrote and has stood the test of time, chances are, you are still updating it, which isn't a bad thing. It keeps you working. :-)
- Patience is definitely a virtue - When clients, friends, or family members use a PC, they get frustrated and proceed to hit a component of the PC or storm off. I keep telling everyone, "you are controlling the computer not the other way around." You need to have a certain level of patience for programming computers. As soon as programmers understand what they did wrong, they look at it from the computers point of view and say, "Oh, that's why it was doing that."
November 10, 2010
What make code "looks" more professional?
author: Micheal Lu
这么题目看起来就比较有争议：运行起来专业的代码才专业嘛。但是从另外一个角度来说"让代码看上去比较专业"是一个积极的做法，无论对谁都没有坏处，对工程师，管理者和用户都有益无弊。
首先这个题目说的是"看上去",所以我不会说明如何使代码真正专业。世界上有很多的书籍和文章告诉软件工程师如何写出专业的代码。如果要说"什么样的代码看上去比较专业？"那就要定义什么是专业的代码。嗯，关于这点我不能下一个准确的定义。那么可以这样，大家可以参考一些大家共认的专业代码。对于Java JDK代码来说几乎没人会否认它是专业的代码。或者一些很有影响力的open source代码，像Spring 和Apache 的代码。当然很多商业软件的代码也是很专业，但是我们看不到，或者说这不是共认的专业代码。
* 最显而易见的做法是充足的代码注释 和标准缩进 的格式。但是大家一致认为这是最明显的因素。
* 然后是命名规范 。有人曾经在网上展示自己的一个framework的代码,framework自然是很牛的东西。但是接下来马上有人回帖"我一看到大写开头的方法名，我就没兴趣了"。这是个很典型的例子。
命名规范里面用拼音 做包名，类名，方法和变量名字也会使代码看上去感觉比较差。我说的是代码，不是注释。
* 还有就是要用最新的语言特性 。对于Java,譬如要用Annotaion, Generic。虽然这些特性已经出现很多年了。至少要用@Override 一下吧。我知道大家知道用Annotaion, Generic的真正的益处。
* 尽量不要用Magic number 。如果一看到到处都是"id".equals(...); if(i==356). ..大家就会感觉不好。
* 还有就是最好包含单元测试 的代码，JUnit 已经成为Java的公认单元测试工具。很多开发人员认为对于一个严肃的程序，单元测试是必需的。
* 避免冗长的方法和类。我知道大家深受其害。
其实我认为"看上去"专业能促进代码质量。充足的代码注释和标准缩进的格式能增强可读性，另外在撰写注释的时候也是在"拷问"自己的代码，如果你觉得某个方法的注释很难写，那就要问问自己的这个方法的代码逻辑写得不够清晰。有时候在注释方法的@throws XXXException 的时候，你才会仔细考虑哪些Exception会在什么情况下被抛出。@Override 能够避免低级打字错误。Generic容器比较安全等等。
从代码演变的角度来说，有个明显的"破窗理论"在起作用。就是越是难看的代码，在它的演化过程中会越来越差。因为当你看到你要bugfix的代码很乱，那么在bugfix的时候一般也会草草了事。一个方法有400行，在修改这个方法的时候大家不会在意再加上几十行代码。因为它看起来很差，它就是很差，我没必要美化它。反过来说，如果待改的代码很整洁很规范，那么修改者也会比较小心。这不是绝对，只是一般情况。一定有很帅的工程师把很难看的代码改得很整洁，也一定有很无畏的工程师在很好的代码上面乱改，这就是生活:)
这么题目看起来就比较有争议：运行起来专业的代码才专业嘛。但是从另外一个角度来说"让代码看上去比较专业"是一个积极的做法，无论对谁都没有坏处，对工程师，管理者和用户都有益无弊。
首先这个题目说的是"看上去",所以我不会说明如何使代码真正专业。世界上有很多的书籍和文章告诉软件工程师如何写出专业的代码。如果要说"什么样的代码看上去比较专业？"那就要定义什么是专业的代码。嗯，关于这点我不能下一个准确的定义。那么可以这样，大家可以参考一些大家共认的专业代码。对于Java JDK代码来说几乎没人会否认它是专业的代码。或者一些很有影响力的open source代码，像Spring 和Apache 的代码。当然很多商业软件的代码也是很专业，但是我们看不到，或者说这不是共认的专业代码。
* 最显而易见的做法是充足的代码注释 和标准缩进 的格式。但是大家一致认为这是最明显的因素。
* 然后是命名规范 。有人曾经在网上展示自己的一个framework的代码,framework自然是很牛的东西。但是接下来马上有人回帖"我一看到大写开头的方法名，我就没兴趣了"。这是个很典型的例子。
命名规范里面用拼音 做包名，类名，方法和变量名字也会使代码看上去感觉比较差。我说的是代码，不是注释。
* 还有就是要用最新的语言特性 。对于Java,譬如要用Annotaion, Generic。虽然这些特性已经出现很多年了。至少要用@Override 一下吧。我知道大家知道用Annotaion, Generic的真正的益处。
* 尽量不要用Magic number 。如果一看到到处都是"id".equals(...); if(i==356). ..大家就会感觉不好。
* 还有就是最好包含单元测试 的代码，JUnit 已经成为Java的公认单元测试工具。很多开发人员认为对于一个严肃的程序，单元测试是必需的。
* 避免冗长的方法和类。我知道大家深受其害。
其实我认为"看上去"专业能促进代码质量。充足的代码注释和标准缩进的格式能增强可读性，另外在撰写注释的时候也是在"拷问"自己的代码，如果你觉得某个方法的注释很难写，那就要问问自己的这个方法的代码逻辑写得不够清晰。有时候在注释方法的@throws XXXException 的时候，你才会仔细考虑哪些Exception会在什么情况下被抛出。@Override 能够避免低级打字错误。Generic容器比较安全等等。
从代码演变的角度来说，有个明显的"破窗理论"在起作用。就是越是难看的代码，在它的演化过程中会越来越差。因为当你看到你要bugfix的代码很乱，那么在bugfix的时候一般也会草草了事。一个方法有400行，在修改这个方法的时候大家不会在意再加上几十行代码。因为它看起来很差，它就是很差，我没必要美化它。反过来说，如果待改的代码很整洁很规范，那么修改者也会比较小心。这不是绝对，只是一般情况。一定有很帅的工程师把很难看的代码改得很整洁，也一定有很无畏的工程师在很好的代码上面乱改，这就是生活:)
Susan Sontag: a letter to Borges
13 June 1996 New York
Dear Borges,
Since your literature was always placed under the sign of eternity, it doesn't seem too odd to be addressing a letter to you. (Borges, it's 10 years!) If ever a contemporary seemed destined for literary immortality, it was you. You were very much the product of your time, your culture, and yet you knew how to transcend your time, your culture, in ways that seem quite magical. This had something to do with the openness and generosity of your attention. You were the least egocentric, the most transparent of writers, as well as the most artful. It also had something to do with a natural purity of spirit. Though you lived among us for a rather long time, you perfected practices of fastidiousness and of detachment that made you an expert mental traveller to other eras as well. You had a sense of time that was different from other people's. The ordinary ideas of past, present and future seemed banal under your gaze. You liked to say that every moment of time contains the past and the future, quoting (as I remember) the poet Browning, who wrote something like, "the present is the instant in which the future crumbles into the past.'' That, of course, was part of your modesty: your taste for finding your ideas in the ideas of other writers.
Your modesty was part of the sureness of your presence. You were a discoverer of new joys. A pessimism as profound, as serene, as yours did not need to be indignant. It had, rather, to be inventive – and you were, above all, inventive. The serenity and the transcendence of self that you found are to me exemplary. You showed that it is not necessary to be unhappy, even while one is clear-eyed and undeluded about how terrible everything is. Somewhere you said that a writer–delicately you added: all persons – must think that whatever happens to him or her is a resource. (You were speaking of your blindness.) You have been a great resource, for other writers. In 1982 – that is, four years before you died – I said in an interview, "There is no writer living today who matters more to other writers than Borges. Many people would say he is the greatest living writer... Very few writers of today have not learnt from him or imitated him.''
That is still true. We are still learning from you. We are still imitating you. You gave people new ways of imagining, while proclaiming over and over our indebtedness to the past, above all, to literature. You said that we owe literature almost everything we are and what we have been. If books disappear, history will disappear, and human beings will also disappear. I am sure you are right. Books are not only the arbitrary sum of our dreams, and our memory. They also give us the model of self-transcendence. Some people think of reading only as a kind of escape: an escape from the "real'' everyday world to an imaginary world, the world of books. Books are much more. They are a way of being fully human.
I'm sorry to have to tell you that books are now considered an endangered species. By books, I also mean the conditions of reading that make possible literature and its soul effects. Soon, we are told, we will call up on "bookscreens'' any "text'' on demand, and will be able to change its appearance, ask questions of it, "interact'' with it. When books become "texts'' that we "interact'' with according to criteria of utility, the written word will have become simply another aspect of our advertising-driven televisual reality. This is the glorious future being created, and promised to us, as something more "democratic''. Of course, it means nothing less then the death of inwardness – and of the book.
This time around, there will be no need for a great conflagration. The barbarians don't have to burn the books. The tiger is in the library. Dear Borges, please understand that it gives me no satisfaction to complain. But to whom could such complaints about the fate of books–of reading itself – be better addressed than to you? (Borges, it's 10 years!) All I mean to say is that we miss you. I miss you. You continue to make a difference. The era we are entering now, this 21st century, will test the soul in new ways. But, you can be sure, some of us are not going to abandon the Great Library. And you will continue to be our patron and our hero.
Extracted from 'Where the Stress Falls' by Susan Sontag (Jonathan Cape, £17.99).
Dear Borges,
Since your literature was always placed under the sign of eternity, it doesn't seem too odd to be addressing a letter to you. (Borges, it's 10 years!) If ever a contemporary seemed destined for literary immortality, it was you. You were very much the product of your time, your culture, and yet you knew how to transcend your time, your culture, in ways that seem quite magical. This had something to do with the openness and generosity of your attention. You were the least egocentric, the most transparent of writers, as well as the most artful. It also had something to do with a natural purity of spirit. Though you lived among us for a rather long time, you perfected practices of fastidiousness and of detachment that made you an expert mental traveller to other eras as well. You had a sense of time that was different from other people's. The ordinary ideas of past, present and future seemed banal under your gaze. You liked to say that every moment of time contains the past and the future, quoting (as I remember) the poet Browning, who wrote something like, "the present is the instant in which the future crumbles into the past.'' That, of course, was part of your modesty: your taste for finding your ideas in the ideas of other writers.
Your modesty was part of the sureness of your presence. You were a discoverer of new joys. A pessimism as profound, as serene, as yours did not need to be indignant. It had, rather, to be inventive – and you were, above all, inventive. The serenity and the transcendence of self that you found are to me exemplary. You showed that it is not necessary to be unhappy, even while one is clear-eyed and undeluded about how terrible everything is. Somewhere you said that a writer–delicately you added: all persons – must think that whatever happens to him or her is a resource. (You were speaking of your blindness.) You have been a great resource, for other writers. In 1982 – that is, four years before you died – I said in an interview, "There is no writer living today who matters more to other writers than Borges. Many people would say he is the greatest living writer... Very few writers of today have not learnt from him or imitated him.''
That is still true. We are still learning from you. We are still imitating you. You gave people new ways of imagining, while proclaiming over and over our indebtedness to the past, above all, to literature. You said that we owe literature almost everything we are and what we have been. If books disappear, history will disappear, and human beings will also disappear. I am sure you are right. Books are not only the arbitrary sum of our dreams, and our memory. They also give us the model of self-transcendence. Some people think of reading only as a kind of escape: an escape from the "real'' everyday world to an imaginary world, the world of books. Books are much more. They are a way of being fully human.
I'm sorry to have to tell you that books are now considered an endangered species. By books, I also mean the conditions of reading that make possible literature and its soul effects. Soon, we are told, we will call up on "bookscreens'' any "text'' on demand, and will be able to change its appearance, ask questions of it, "interact'' with it. When books become "texts'' that we "interact'' with according to criteria of utility, the written word will have become simply another aspect of our advertising-driven televisual reality. This is the glorious future being created, and promised to us, as something more "democratic''. Of course, it means nothing less then the death of inwardness – and of the book.
This time around, there will be no need for a great conflagration. The barbarians don't have to burn the books. The tiger is in the library. Dear Borges, please understand that it gives me no satisfaction to complain. But to whom could such complaints about the fate of books–of reading itself – be better addressed than to you? (Borges, it's 10 years!) All I mean to say is that we miss you. I miss you. You continue to make a difference. The era we are entering now, this 21st century, will test the soul in new ways. But, you can be sure, some of us are not going to abandon the Great Library. And you will continue to be our patron and our hero.
Extracted from 'Where the Stress Falls' by Susan Sontag (Jonathan Cape, £17.99).
November 1, 2010
(ZT) some important algorithms
下面是一些比较重要的算法，原文罗 列了32个，但我觉得有很多是数论里的，和计算机的不相干，所以没有选取。下面的这些，有的我们经常在用，有的基本不用。有的很常见，有的很偏。不过了解 一下也是好事。也欢迎你留下你觉得有意义的算法。（注：本篇文章并非翻译，其中的算法描述大部份摘自Wikipedia，因为维基百科描述的很专业了）
A*搜寻算法
俗称A星算法。这是一种在图形平面上，有多个节点的路径，求出最低通过成本的算法。常用于游戏中的NPC的移动计算，或线上游戏的BOT的移动计算上。该算法像Dijkstra算法一样，可以找到一条最短路径；也像BFS一样，进行启发式的搜索。
Beam Search
束 搜索(beam search)方法是解决优化问题的一种启发式方法，它是在分枝定界方法基础上发展起来的，它使用启发式方法估计k个最好的路径，仅从这k个路径出发向下 搜索，即每一层只有满意的结点会被保留，其它的结点则被永久抛弃，从而比分枝定界法能大大节省运行时间。束搜索于20 世纪70年代中期首先被应用于人工智能领域,1976 年Lowerre在其称为HARPY的语音识别系统中第一次使用了束搜索方法，他的目标是并行地搜索几个潜在的最优决策路径以减少回溯，并快速地获得一个 解。
二分取中查找算法一 种在有序数组中查找某一特定元素的搜索算法。搜素过程从数组的中间元素开始，如果中间元素正好是要查找的元素，则搜素过程结束；如果某一特定元素大于或者 小于中间元素，则在数组大于或小于中间元素的那一半中查找，而且跟开始一样从中间元素开始比较。这种搜索算法每一次比较都使搜索范围缩小一半。
Branch and bound
分支定界(branch and bound)算法是一种在问题的解空间树上搜索问题的解的方法。但与回溯算法不同，分支定界算法采用广度优先或最小耗费优先的方法搜索解空间树，并且，在分支定界算法中，每一个活结点只有一次机会成为扩展结点。
数据压缩
数据压缩是通过减少计算机中所存储数据或者通信传播中数据的冗余度，达到增大数据密度，最终使数据的存储空间减少的技术。数据压缩在文件存储和分布式系统领域有着十分广泛的应用。数据压缩也代表着尺寸媒介容量的增大和网络带宽的扩展。
Diffie�Hellman密钥协商Diffie�Hellman key exchange，简称"D�H"，是一种安全协议。它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道建立起一个密钥。这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容。
Dijkstra's 算法迪 科斯彻算法（Dijkstra）是由荷兰计算机科学家艾兹格・迪科斯彻（Edsger Wybe Dijkstra）发明的。算法解决的是有向图中单个源点到其他顶点的最短路径问题。举例来说，如果图中的顶点表示城市，而边上的权重表示著城市间开车行 经的距离，迪科斯彻算法可以用来找到两个城市之间的最短路径。
动态规划
动 态规划是一种在数学和计算机科学中使用的，用于求解包含重叠子问题的最优化问题的方法。其基本思想是，将原问题分解为相似的子问题，在求解的过程中通过子 问题的解求出原问题的解。动态规划的思想是多种算法的基础，被广泛应用于计算机科学和工程领域。比较著名的应用实例有：求解最短路径问题，背包问题，项目 管理，网络流优化等。这里也有一篇文章说得比较详细。
欧几里得算法
在数学中，辗转相除法，又称欧几里得算法，是求最大公约数的算法。辗转相除法首次出现于欧几里得的《几何原本》（第VII卷，命题i和ii）中，而在中国则可以追溯至东汉出现的《九章算术》。
最大期望（EM）算法在 统计计算中，最大期望（EM）算法是在概率（probabilistic）模型中寻找参数最大似然估计的算法，其中概率模型依赖于无法观测的隐藏变量 （Latent Variable）。最大期望经常用在机器学习和计算机视觉的数据聚类（Data Clustering）领域。最大期望算法经过两个步骤交替进行计算，第一步是计算期望（E），利用对隐藏变量的现有估计值，计算其最大似然估计值；第二 步是最大化（M），最大化在 E 步上求得的最大似然值来计算参数的值。M 步上找到的参数估计值被用于下一个 E 步计算中，这个过程不断交替进行。
快速傅里叶变换(FFT)快 速傅里叶变换（Fast Fourier Transform，FFT），是离散傅里叶变换的快速算法，也可用于计算离散傅里叶变换的逆变换。快速傅里叶变换有广泛的应用，如数字信号处理、计算大 整数乘法、求解偏微分方程等等。本条目只描述各种快速算法，对于离散傅里叶变换的性质和应用，请参见离散傅里叶变换。
哈希函数
HashFunction 是一种从任何一种数据中创建小的数字"指纹"的方法。该函数将数据打乱混合，重新创建一个叫做散列值的指纹。散列值通常用来代表一个短的随机字母和数字组 成的字符串。好的散列函数在输入域中很少出现散列冲突。在散列表和数据处理中，不抑制冲突来区别数据，会使得数据库记录更难找到。
堆排序
Heapsort是指利用堆积树（堆）这种数据结构所设计的一种排序算法。堆积树是一个近似完全二叉树的结构，并同时满足堆积属性：即子结点的键值或索引总是小于（或者大于）它的父结点。
归并排序
Merge sort是建立在归并操作上的一种有效的排序算法。该算法是采用分治法（Divide and Conquer）的一个非常典型的应用。
RANSAC 算法
RANSAC 是"RANdom SAmpleConsensus"的缩写。该算法是用于从一组观测数据中估计数学模型参数的迭代方法，由Fischler and Bolles在1981提出，它是一种非确定性算法，因为它只能以一定的概率得到合理的结果，随着迭代次数的增加，这种概率是增加的。该算法的基本假设是 观测数据集中存在"inliers"（那些对模型参数估计起到支持作用的点）和"outliers"（不符合模型的点），并且这组观测数据受到噪声影响。 RANSAC 假设给定一组"inliers"数据就能够得到最优的符合这组点的模型。
RSA加密演算法
这是一个公钥加密算法，也是世界上第一个适合用来做签名的算法。今天的RSA已经专利失效，其被广泛地用于电子商务加密，大家都相信，只要密钥足够长，这个算法就会是安全的
并查集Union-find
并查集是一种树型的数据结构，用于处理一些不相交集合（Disjoint Sets）的合并及查询问题。常常在使用中以森林来表示。
Viterbi algorithm
寻找最可能的隐藏状态序列(Finding most probable sequence of hidden states)
BTY:
关于这个世界上的算法，你可以看看Wikipedia的这个网页：http://en.wikipedia.org/wiki/List_of_algorithms
关于排序算法，你可以看看本站的这几篇文章《一个显示排序过程的Python脚本》、《一个排序算法比较的网站》
A*搜寻算法
俗称A星算法。这是一种在图形平面上，有多个节点的路径，求出最低通过成本的算法。常用于游戏中的NPC的移动计算，或线上游戏的BOT的移动计算上。该算法像Dijkstra算法一样，可以找到一条最短路径；也像BFS一样，进行启发式的搜索。
Beam Search
束 搜索(beam search)方法是解决优化问题的一种启发式方法，它是在分枝定界方法基础上发展起来的，它使用启发式方法估计k个最好的路径，仅从这k个路径出发向下 搜索，即每一层只有满意的结点会被保留，其它的结点则被永久抛弃，从而比分枝定界法能大大节省运行时间。束搜索于20 世纪70年代中期首先被应用于人工智能领域,1976 年Lowerre在其称为HARPY的语音识别系统中第一次使用了束搜索方法，他的目标是并行地搜索几个潜在的最优决策路径以减少回溯，并快速地获得一个 解。
二分取中查找算法一 种在有序数组中查找某一特定元素的搜索算法。搜素过程从数组的中间元素开始，如果中间元素正好是要查找的元素，则搜素过程结束；如果某一特定元素大于或者 小于中间元素，则在数组大于或小于中间元素的那一半中查找，而且跟开始一样从中间元素开始比较。这种搜索算法每一次比较都使搜索范围缩小一半。
Branch and bound
分支定界(branch and bound)算法是一种在问题的解空间树上搜索问题的解的方法。但与回溯算法不同，分支定界算法采用广度优先或最小耗费优先的方法搜索解空间树，并且，在分支定界算法中，每一个活结点只有一次机会成为扩展结点。
数据压缩
数据压缩是通过减少计算机中所存储数据或者通信传播中数据的冗余度，达到增大数据密度，最终使数据的存储空间减少的技术。数据压缩在文件存储和分布式系统领域有着十分广泛的应用。数据压缩也代表着尺寸媒介容量的增大和网络带宽的扩展。
Diffie�Hellman密钥协商Diffie�Hellman key exchange，简称"D�H"，是一种安全协议。它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道建立起一个密钥。这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容。
Dijkstra's 算法迪 科斯彻算法（Dijkstra）是由荷兰计算机科学家艾兹格・迪科斯彻（Edsger Wybe Dijkstra）发明的。算法解决的是有向图中单个源点到其他顶点的最短路径问题。举例来说，如果图中的顶点表示城市，而边上的权重表示著城市间开车行 经的距离，迪科斯彻算法可以用来找到两个城市之间的最短路径。
动态规划
动 态规划是一种在数学和计算机科学中使用的，用于求解包含重叠子问题的最优化问题的方法。其基本思想是，将原问题分解为相似的子问题，在求解的过程中通过子 问题的解求出原问题的解。动态规划的思想是多种算法的基础，被广泛应用于计算机科学和工程领域。比较著名的应用实例有：求解最短路径问题，背包问题，项目 管理，网络流优化等。这里也有一篇文章说得比较详细。
欧几里得算法
在数学中，辗转相除法，又称欧几里得算法，是求最大公约数的算法。辗转相除法首次出现于欧几里得的《几何原本》（第VII卷，命题i和ii）中，而在中国则可以追溯至东汉出现的《九章算术》。
最大期望（EM）算法在 统计计算中，最大期望（EM）算法是在概率（probabilistic）模型中寻找参数最大似然估计的算法，其中概率模型依赖于无法观测的隐藏变量 （Latent Variable）。最大期望经常用在机器学习和计算机视觉的数据聚类（Data Clustering）领域。最大期望算法经过两个步骤交替进行计算，第一步是计算期望（E），利用对隐藏变量的现有估计值，计算其最大似然估计值；第二 步是最大化（M），最大化在 E 步上求得的最大似然值来计算参数的值。M 步上找到的参数估计值被用于下一个 E 步计算中，这个过程不断交替进行。
快速傅里叶变换(FFT)快 速傅里叶变换（Fast Fourier Transform，FFT），是离散傅里叶变换的快速算法，也可用于计算离散傅里叶变换的逆变换。快速傅里叶变换有广泛的应用，如数字信号处理、计算大 整数乘法、求解偏微分方程等等。本条目只描述各种快速算法，对于离散傅里叶变换的性质和应用，请参见离散傅里叶变换。
哈希函数
HashFunction 是一种从任何一种数据中创建小的数字"指纹"的方法。该函数将数据打乱混合，重新创建一个叫做散列值的指纹。散列值通常用来代表一个短的随机字母和数字组 成的字符串。好的散列函数在输入域中很少出现散列冲突。在散列表和数据处理中，不抑制冲突来区别数据，会使得数据库记录更难找到。
堆排序
Heapsort是指利用堆积树（堆）这种数据结构所设计的一种排序算法。堆积树是一个近似完全二叉树的结构，并同时满足堆积属性：即子结点的键值或索引总是小于（或者大于）它的父结点。
归并排序
Merge sort是建立在归并操作上的一种有效的排序算法。该算法是采用分治法（Divide and Conquer）的一个非常典型的应用。
RANSAC 算法
RANSAC 是"RANdom SAmpleConsensus"的缩写。该算法是用于从一组观测数据中估计数学模型参数的迭代方法，由Fischler and Bolles在1981提出，它是一种非确定性算法，因为它只能以一定的概率得到合理的结果，随着迭代次数的增加，这种概率是增加的。该算法的基本假设是 观测数据集中存在"inliers"（那些对模型参数估计起到支持作用的点）和"outliers"（不符合模型的点），并且这组观测数据受到噪声影响。 RANSAC 假设给定一组"inliers"数据就能够得到最优的符合这组点的模型。
RSA加密演算法
这是一个公钥加密算法，也是世界上第一个适合用来做签名的算法。今天的RSA已经专利失效，其被广泛地用于电子商务加密，大家都相信，只要密钥足够长，这个算法就会是安全的
并查集Union-find
并查集是一种树型的数据结构，用于处理一些不相交集合（Disjoint Sets）的合并及查询问题。常常在使用中以森林来表示。
Viterbi algorithm
寻找最可能的隐藏状态序列(Finding most probable sequence of hidden states)
BTY:
关于这个世界上的算法，你可以看看Wikipedia的这个网页：http://en.wikipedia.org/wiki/List_of_algorithms
关于排序算法，你可以看看本站的这几篇文章《一个显示排序过程的Python脚本》、《一个排序算法比较的网站》
Subscribe to:
Posts (Atom)
Days of our lives
