|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|How to Solve It|
|Programming Pearls||The True Believer||Lions' Commentary on Unix||K&R Book||Rapid Development||Winner-Take-All Politics||Military Incompetence|
|Alice's Adventures in Wonderland||Tao of programming||AWK book||Animal Farm||The Elements of Programming Style||Humor||Etc|
For Unix sysadmins this is a perfect books about principles of troubleshooting as a problem solving activity
George Polya(1887-1985) was a famous mathematician, who got importance results in probability, analysis, number theory, geometry, combinatorics and mathematical physics. His book How to Solve It was probably the most significant contribution to heuristic since Descartes' Discourse on Method. And its value is not limited to mathematic. For Unix sysadmins this is a perfect books about principles of troubleshooting as a problem solving activity
In this book he proposed structuring the problem-solving process into four stages (see How To Solve It Step-by-step Plan ).
For each stage George Polya supplied a series of questions that help to solve the problem. Some of them are:
For complete list questions in a form of step-by-step plan see How To Solve It Step-by-step Plan
The examples in the book are drawn mostly from elementary math, but the method is quite general and applies to nearly every problem one might encounter. It is especially valuable for solving programming problems. I read it when I was 15 years old and this was the only mathematical book that I really liked. I thought that it contains amazing insights into problem solving skills. That perception was wrong as for my mathematical successes but later my intensive study of the book paid off somewhat in programming. Or at least I tend to think so.
BTW it was George Polya, who said "There are many questions which fools can ask that wise men cannot answer." (See H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988).
IMHO the book is much more valuable to programmers than all modern "pattern" stuff (although the latter might be useful too, but only in great moderation ;-). The only review of the book in programming literature that I found was a review in DDJ. BTW Microsoft used to give this book to all of its new programmers. Probably not any more ;-).
See also: Synthesis of Research on Problem Solving.
27-190 Discrete Structures in Computer Science Techniques of Proof and Problem Solving
For every problem you can’t solve there exists an easier problem that you can: find it.
"Geometry is the science of correct reasoning on incorrect figures."
"My method to overcome a difficulty is to go round it."
Quite often, when an idea that could be helpful presents itself, we do not appreciate it, for it is so inconspicuous. The expert has, perhaps, no more ideas than the inexperienced, but appreciates more what he has and uses it better.
— George PólyaHow to Solve it: A New Aspect of Mathematical Method (1957), 223.
Mathematics is the cheapest science. Unlike physics or chemistry, it does not require any expensive equipment. All one needs for mathematics is a pencil and paper.
D. J. Albers and G. L. Alexanderson, Mathematical People, Boston: Birkhäuser, 1985.
Mathematics consists of proving the most obvious thing in the least obvious way.
In N. Rose Mathematical Maxims and Minims, Raleigh NC:Rome Press Inc., 1988.
When introduced at the wrong time or place, good logic may be the worst enemy of good teaching.
The American Mathematical Monthly, v. 100, no. 3.
The traditional mathematics professor of the popular legend is absentminded. He usually appears in public with a lost umbrella in each hand. He prefers to face the blackboard and to turn his back to the class. He writes a, he says b, he means c; but it should be d. Some of his sayings are handed down from generation to generation:
"In order to solve this differential equation you look at it till a solution occurs to you."
"This principle is so perfectly general that no particular application of it is possible."
"What is the difference between method and device? A method is a device which you used twice."
How to Solve It. Princeton: Princeton University Press. 1945.The future mathematician ... should solve problems, choose the problems which are in his line, meditate upon their solution, and invent new problems. By this means, and by all other means, he should endeavor to make his first important discovery: he should discover his likes and dislikes, his taste, his own line.
Even fairly good students, when they have obtained the solution of the problem and written down neatly the argument, shut their books and look for something else. Doing so, they miss an important and instructive phase of the work. ... A good teacher should understand and impress on his students the view that no problem whatever is completely exhausted. One of the first and foremost duties of the teacher is not to give his students the impression that mathematical problems have little connection with each other, and no connection at all with anything else. We have a natural opportunity to investigate the connections of a problem when looking back at its solution.
How to Solve It. Princeton: Princeton University Press. 1945
In How To Solve It, G. Polya describes four steps for solving problems and outlines them at the very beginning of the book for easy reference. The steps outline a series of general questions that the problem solving student can use to successfully write resolutions. Without the questions, common sense goes through the same process; the questions simply allow students to see the process on paper. Polya designed the questions to be general enough that students could apply them to almost any problem.
The four steps are:
- understanding the problem,
- devising a plan,
- carrying out the plan, and
- looking back.
This method is very similar to the method in Thinking Mathematically by John Mason, except Polya separates devising a plan, and carrying out the plan. This may seem silly at first, but Polya argues that it does make a difference. By first devising a plan, students can eliminate mistakes they might make by rushing into the actual execution of the plan. When they plan it out first and then do the math, it is possible to check their work as they go along.
In the first step, students should be able to state the unknown, or the thing they want to find to answer the question, the data the question gives them to work with, and the condition, or limiting circumstances they must work around. If they can identify all of these, and explain the question to other people, then they have a good understanding of what the problem is asking. Polya suggests that students draw a picture if possible, or introduce some kind of notation to visualize the question.
To devise a plan, students can start by trying to think of a related problem they have solved before to help them. If the student can think of a problem they have solved before that had a similar unknown, it could also be helpful. Students can also try to restate the problem in an easier or different way, and try to solve that. By looking at these related problems, students may be able to use the same method, or other part of the plan used. After students have decided which calculations, computations, or constructions that they need, and have made sure that all data and conditions were used, they can try out their plan. To carry out the plan, they must do all the calculations, and check them as they go along. Then they should ask themselves, "Can I see it is right?" and then, "Can I prove it is right?"
When students look back on the problem and the plan they carried out, they can increase their understanding of the solution. It is always good to recheck the result and argument used, and to make sure that it is possible to check them. Then students should ask, "Can I get the result in a different way?" and "Can I use this for another problem?" The last chapter of the book is a very helpful encyclopedia of the terms used in the explanation of the first chapter.
By Beth Nuckolls.
A few links:
A recurring theme throughout the book is that if you can not solve a problem, then you should find an easier but similar one. ‘Do you know a related problem?’ Polya would ask. For example, suppose the student has just learned the Pythagorean theorem, and is now asked to find the length of the spatial diagonal of a parallelepiped.
A small amount of ingenuity is required to make the jump from the plane to the space, and the student is naturally stumped. ‘Do you know a problem with a similar unknown?’ the teacher asks.
The student gets a brilliant insight – a previously solved problem. ‘Good!
Here’s a problem related to yours and solved before. Can you use it?’ the teacher presses on. Eventually the solution is found, and all is well. Of course, the point of that passage is not to introduce to the readers the Pythagorean theorem in higher dimensions, but to show the readers the process with which one can use to find an ‘auxiliary problem’ that has been solved and use it to solve the harder problem. Polya himself is often accredited the quote, ‘For every problem you can’t solve there exists an easier problem that you can: find it.
Unfortunately, the effectiveness of the book is debatable. As Feynman said, ‘You can’t learn to solve problems by reading about it.’ There is no other way of gaining problem-solving experience save for actually solving problems. Hence, ironically, it is hard to appreciate the book unless you no longer need it.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2015 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: October 20, 2014