Structures: Or why things don’t fall down by J.E. Gordon

• A structure has been defined as ‘any assemblage of materials which is intended to sustain loads’, and the study of structures is one of the traditional branches of science.
• Structures can, and do, break, and this may be important and sometimes dramatic; but, in conventional technology the rigidity and deflections of a structure before it breaks are likely to be more important in practice.
• Structures are made from materials and we shall talk about structures and also about materials; but in fact there is no clear-cut dividing line between a material and a structure.
• In other words, a force cannot just get lost. Always and whatever happens every force must be balanced and react by another equal and opposite force at every point throughout a structure. This is true for any kind of structure, however small and simple or however large and complicated it may be.
• In may structures, such as buildings, the load is carried in compression, that is by pushing.
• Thus if any structural system is to do its job--that is to say, if the load is supported in a satisfactory way so that nothing very much happens--then it must somehow manage to produce a push or a pull which is exactly equal and opposite to the force which is being applied to it.
• Every kind of solid changes its shape--by stretching or contracting itself--when a mechanical force is applied to it.
• All materials and structures deflect, to greatly varying extends, when they are loaded. The science of elasticity is about the interactions between forces and deflections.
• It is this change of shape which enables the solid to do the pushing bac.
• All materials and structures deflect, although to greatly varying extents, when they are loaded.
• It is important to realize that it is perfectly normal for any and every structure to deflect in response to a load.
• The science of elasticity is about the interactions between forces and deflections in materials and structures.
• When any structure deflects under load in the way we have been talking about, the material from which it is made is itself also stretched or contracted, internally, throughout all its parts and in due proportion, down to a very fine scale--as we know nowadays, down to a molecular scale. Thus, when we deform a stick or a steel spring--day by bending it--the atoms and molecules of which the material is made have to move further apart, or else squash together, when the material as a whole is stretched or compressed.
• If we think for one moment, it is obvious that the deflection of a structure is affected both by its size and geometrical shape and also by the sort of material from which it is made.
• Materials vary very greatly in their intrinsic stiffness.
• Other things being equal, a rod which is pulled in tension has a strength which is proportional to its cross-sectional area.
• In other words the ‘stress’ in a solid is rather like the ‘pressure’ in a liquid of a gas. It is a measure of how hard the atoms and molecules which make up the material are being pushed together or pulled apart as a result of external forces.
• Just as stress tell us how hard--that it, with how much force--the atoms at any point in a solid are being pulled apart, so strain tells us how far they are being pulled apart--that is, by what proportion the bonds between the atoms are stretched.
• The strength of a structure is simple the load which will just break the structure. This figure is known as the ‘breaking load’, and it naturally applies only to some individual, specific structure.
• The strength of a material is the stress required to break a piece of the material itself. It will generally be the same for all specimens of any given solid.
• The strong metals are rather stronger, on the whole, than the strong non-metals. However, nearly all metals are considerably denser than most biological materials. This, strength for weight, metals are not too impressive when compared with plants and animals.
• Stress = load / area
• Strain = extension under load / original length
• By the strength of a material we usually mean that stress which is needed to break it.
• Iron and steel usually vary in strength by only a few percent and very, vary rarely by anything like a factor of three or four, let alone seven or eight.
• Geometrical irregularities, such as holes and cracks and sharp corners, which had previously been ignored, may raise the local stress--often only over a very small area--very dramatically indeed. Thus holes and notches may cause the stress in their immediate vicinity to be much higher than the breaking stress of the material, even when the general level of stress in the surrounding neighborhood is low and , from general calculating, the structure might appear to be perfectly safe.
• When we see to ‘strengthen’ something by adding extra material we have to be careful we do not in fact make it weaker.
• Energy can exist in a great variety of different forms--as potential energy, as heat energy, as chemical energy, as electrical energy and so on.
• In our material world, every single happening or event of whatever kind involves a conversion of energy from one into another of its many forms.
• Energy can neither be created nor destroyed, and so the total amount of energy which is present before and after any physical transaction will not be changed.
• The bow is one of the most effective ways of storing the energy of human muscles and releasing it to people a missile weapon.
• This quality of being able to store strain energy and deflect elastically under a load without breaking is called ‘resilience’, and it is a very valuable characteristic in a structure. Resilience may be defined as ‘the amount of strain energy which can be stored in a structure without causing permanent damage to it’.
• A reasonable amount of resilience is an essential quality in any structure; otherwise it would be unable to absorb the energy of a blow. Up to a point, the more resilient a structure is the better.
• All elastic substances which are under load contain greater or less amounts of strain energy, and this strain energy is always potentially available for the self-destructive process which we call ‘fracture’.
• Since, when a solid is broken in tension, at least one crack must be made to spread right across the material, so as to divide it into two parts, at least two new surfaces will have to be created which did not exist before fracture. IN order to tear the material apart in this way and produce these new surfaces it is necessary to have broken all the chemical bonds which previously held the two surfaces together.
• The easiest structure to think about are generally those which have to resist only tensile forces--forces which pull rather than push--and, of these, the simplest of all are those which have to resist only a single pull: in other words unidirectional tension , the basic case of a rope or a rod.
• Since the function of a joint is to transmit load from one element of a structure to its neighbour, stress has somehow got to get itself out of one piece of material and then get itself into the adjoining piece; such a process is only too likely to result in severe concentrations of stress and consequent weakness.
• Creep in any material causes the stress to be redistributed in a manner which is often beneficial, since the more highly stressed parts creep the most.
• Out of all the different kinds of structures which might be made, the masonry building is, as we shall see, the only one in which a blind reliance on traditional proportions will not automatically lead to disaster. This is why, historically, masonry buildings were by far the largest and most imposing of the works of man.
• The basic condition for the safety of masonry is that the thrust line should always be kept well inside the surface of a wall or column.
• The structural function of an arch is to support the downard loads which come upon it by turning them into a lateral thrust which runs round the ring of the arch and pushes the voussoirs against each other. The voussoirs, naturally, push in their turn against the abutments or springings of the arch.
• The strength of any structure which is liable to fail because the material breaks cannot be predicted from models or by scaling up from previous experience.
• Buildings do not normally fail by reason of the material breaking in compression.
• The stresses in masonry are so low that we can afford to go on scaling them up almost indefinitely. Unlike most other structures, buildings fail because they become unstable and tip up; and for any size of building this can be predicted from a model.
• The American railways could be built quickly and cheaply because wooden trestle bridges were used very extensively to save the cost of earthworks.
• In practical terms, the purpose of a bridge is to enable heavy objects, such as vehicles, to cross over some kind of gap or chasm. Provided that the weight is supported in a safe manner it usually does not matter very much by what technical means this is done. As is turns out, there is a very considerable variety of structural principles which can be employed.
• A simple masonry arch can quite safely be built with a span of well over 200 feet.
• The cables of a suspension bridge take up the best shape automatically, because a flexible rope has no choice but to comply with the resultant of all the loads which are pulling on it. We can therefore determine the shape of the cables for a suspension bridge either by loading a model of it, or else by means of a fairly simple exercise with a thing called the ‘funicular polygon’ on the drawing board.
• A solid roof over one’s head is one of the prime requirements of a civilized existence, but permanent roofs are heavy and the problem of supporting them is really as old as civilization itself.
• The first problem in constructing a sailing ship is to erect some kind of mast upon which sail can be hoisted. The second, and much more difficult, problem is to keep that mask in place.
• A load which acts at right angles to the length of the beam is supported without putting any longitudinal force upon whatever is supporting the beam. This is essentially what all beams are for.
• A ‘cantilever’ is a beam one end of which can be considered as being ‘built in’ to some rigid support, such as a wall or the ground.
• A simply supported beam is one which rests freely on supports at both ends.
• Every beam must deflect under the load which is applied to it and it will therefore be destroyed unto a curved or bent shape.
• Material on the concave or compression face of a bent beam will be shortened or strained in compression. Material on the convex or tension face will be lengthened or strained in tension.
• If tension is about pulling and compression is about pushing, then shear is about sliding. In other words, a shear stress measures the tendency for one part of a solid to slide past the next bit: the sort of thing which happens when you throw a pack of cards on the table or jerk the rug from under someone’s feet.
• As long as they are not subjected to ‘unnatural’ loads, most animals can afford to be weak in torsion.
• Not only our legs, but virtually all bones, are surprisingly weak in torsion.
• When we stress a solid in tension we are, of course, pulling its atoms and molecules further apart. As we do so, the interatomic bonds which hold the material together are stretched, but they can be safely stretched only to a limited extend.
• Beyond about 20 percent tensile strain, all chemical bonds become weaker and will eventually come unstuck.
• The actual fracture nearly always takes place by shearing.
• As we said in the last chapter, both tensile and compressive stresses necessarily give rise to shears at 45 degrees; it is these diagonal shears which generally cause ‘compressive failure’ in short struts.
• All practical brittle solids are full of cracks and scratches and defects of one kind or another. Even if this is not the case when they are first made, such materials very soon become abraded from all sorts of virtually unavoidable causes.
• In general, fastenings like nails and screws do not much weaken timber, always provided that they are in place and fit tightly. Once they are removed, however, the resulting hole has a much more serious effect; and no doubt the same is true of knots in timber.
• The use of tubes is extremely popular both with engineers and with Nature, and tubular struts are very widely used for all sorts of purposes.
• In engineering structures, panels and shells are very often stiffened by means of ribs or stringers which are glued or riveted or welded to the plating, through this is not always the lightest or the cheapest way of doing the job.
• The acceptability of various materials changes with time in curious and interesting ways.
• Advanced devices require advanced materials, and the newer materials, such as high-temperature alloys and carbon fibre plastics, consume more and more energy in their manufacture.
• Every structure must be built so as to be ‘safe’ for what may reasonably be considered an appropriate working life.
• In most types of structure, rot and rust are very active agents of decay.
• However, with modern knowledge and methods of treatment, it should be possible to get a practically indefinite life from almost any kind of wood.
• Most metals corrode in service. Modern mild steel rusts very much worse tan Victorian wrought iron or cast iron, and so rust is, to some extent, a modern problem. Because the cost of labour is high, the cost of the painting and maintenance of steelwork is high. This is one good reason for using reinforced concrete, since steel embedded in concrete does not rust.
• One of the most insidious causes of loss of strength in a structure is ‘fatigue’: that is to say, the cumulative effect of fluctuating loads.
• Almost every structure has a tendency to turn out heavier than its designer intended. This is partly due to over-optimistic estimating in the wights office, but it is also due to a tendency on the part of almost everybody to ‘play safe’ by making each part just that much thicker and heavier than is really necessary.
• In nearly all accidents we need to distinguish two different levels of causation. The first is the immediate technical or mechanical reason for the accident; the second is the underlying human reason. It is quite true that design is not a very precise business, that unexpected things happen, that genuine mistakes are made and so forth; but much more often the ‘real’ reason for an accident is preventable human error.
• Nine out of ten accidents are caused, not by more or less abstruse technical effects, but by old fashioned human sin--often verging on plain wickedness.
• People do not become immune from the classical or theological human weaknesses merely because they are operating in a technical situation, and several of these catastrophes have much of the drama and inevitably of Greek tragedy.
• Engineers have to deal, not only with people and all their quirks and weaknesses, but also with physical facts. One can sometimes argue with people, and it is not difficult to deceive them; but it is of no use to argue with a physical fact. One cannot bully it or bribe it or legislate against it or pretend that the truth is something different or that the thing never happened at all.
• It may be the engineer’s job to point out that the emperor has no clothes on, but however embarrassing this may be, we clearly need more, not less, of this kind of realism.
• It is confidence that causes accidents and worry which prevents them. So go over your sums not once or twice but again and again and again.

Thinking Forth by Leo Brodie

• To call forth a concept, a word is needed; to portray a phenomenon, a concept is needed.
• Programming computers can be crazy making.
• Programmers design, build, and repair the stuff of imagination, ghostly mechanisms that escape the senses.
• Our work takes place not in RAM, not in an editor, but within our own minds.
• Forth is a language, an operating system, a set of tools, and a philosophy.
• Assembly-language programming is characterized by a one-for-one correspondence between each command that the programmer types and each command that the processor performs.
• High-level languages are clearly more “powerful” than assembly languages in the sense that each instruction might compile dozens of machine instructions. But more significantly, high-level languages eliminate the linear corresponding between source code and the resulting machines instructions.
• Decisions about the algorithms and associated data structures should be made in parallel.
• Simplicity is the primary measurement recommended for evaluating alternative designs relative to reduced debugging and modification time.
• By dividing a problem into simple modules, programs were expected to be easier to write, easier to change, and easier to understand.
• The safest kind of coupling is the passing of local variables as parameters from one module to another.
• The smallest atom of a Forth program is not a module or a subroutine or a procedure, but a “word”.
• Everything in Forth is a word.
• Calls are implicit.
• Data passing is implicit.
• Because Forth uses a stack for passing data, words can nest within words.
• Forth eliminates from our programmes the details of how words are invoked and how data are passed.
• Because Forth is interactive, the programmer can type and test the primitive commands.
• Forth programming consists of extending the root language toward the application, providing new commands that can be used to describe the problem at hand.
• Forth is a programming environment for creating application-oriented languages.
• The purpose of hiding information is simply to minimize the effects of a possible design-change by localizing things that might change within each component.
• Forth conveniently seperates “things” from “actions” by allowing addresses of data structures to be passed on the stack and providing the “fetch” and “store” commands.
• Forth pays little attention to whether something is a data structure or an algorithm. This indifference allows us programmers incredible freedom in creating the parts of speech we need to describe our applications.
• Forth is a design language.
• Unfortunately, human foresight is limited even under the best conditions. Too much planning becomes counterproductive.
• Constructing a prototype is a more refined way to plan, just as breadboarding is in electronic design.
• Experimentation proves more reliable in arriving at the truth than the guesswork of planning.
• Overall, Forth outdoes all other high-level languages in speed, capability, and compactness.
• Although Forth is an interpretive language, it executes compiled code.
• Forth’s use of a data stack greatly reduces the performance cost of passing arguments from word to word.
• Forth can do anything any other language can do--usually easier.
• Forth can be written to run on top of any operating system or, for those who prefer it, Forth can be written as a self-sufficient operating system including its own terminal drivers and disk drivers.
• Start simple. Get it running. Learn what you’re trying to do. Add complexity gradually, as needed to fit the requirements and constraints. Don’t be afraid to restart from scratch.
• Testing and prototyping are the best ways to discover what is really needed.
• For newcomers to Forth: Keep the analysis phase to a minimum.
• For Forth addicts: Hold off on coding as long as you possibly can.
• Plan for change (by designing components that can be changed).
• Prototype.
• The first step is to determine what the application should do.
• A conceptual model is an imaginary solution to the problem. It is a view of how the system appears to work.
• A design begins to describe how the system really works.
• Strive to build a solid conceptual model before beginning the design.
• First, and most importantly, the conceptual model should describe the system’s interfaces.
• Decide on error- and exception-handling early as part of defining the interface.
• Develop the conceptual model by imagining the data traveling through and being acted upon by the parts of the model.
• Forth encourages you to think in terms of the conceptual model, and Forth’s implicit use of a data stack makes the passing of data among modules so simple it can usually be taken for granted. This is because Forth, used properly, approaches a functional language.
• Most of your efforts at defining a problem will center on describing the interface.
• Visualization of ideas helps in understanding problems, particularly those problems that are too complex to perceive in a linear way.
• You don’t understand a problem until you can simplify it.
• Keep it simple.
• Given two solutions to a problem, the correct one is the simpler.
• Generality usually involves complexity. Don’t generalize your solution any more than will be required; instead, keep it changeable.
• Go back to what the problem was before the customer tried to solve it. Exploit the “don’t cares”.
• To simplify, quantize.
• To simplify, keep the user out of trouble.
• To simplify, take advantage of what’s available.
• Careful planning is essential, because things always take longer than you expect.
• The mean time for making a “two-hour” addition to an application is approximately 12 hours.
• Conventional wisdom reveres complexity.
• Always give your client some options. Clients like options.
• Everything takes longer than you think, including thinking.
• To see the relationship between two things, put them close together. To remind yourself of the relationship, keep them together.
• The goal of preliminary design is to determine what components are necessary to accomplish the requirements.
• Within each component, implement only the commands needed for the current iteration. (But don’t preclude future additions.)
• Definitions are invoked by being named.
• The purpose of an interface component is to implement, and hide information about, the data interface between two or more other components.
• Both data structures and the commands involved in the communication of data between modules should be localized in an interface component.
• We must distinguish between data structures that are validly used only within a single component and those that may be shared by more than one component.
• Express in objective units any data to be shared by components.
• One of Forth’s rules is that a word must already have been defined to be invoked or referred to.
• Most of us are guilty of over-emphasizing the difference between “high-level” and “low-level”. This notion is an arbitrary one. It limits our ability to think clearly about software problems.
• An object is a portion of code that can be invoked by a single name, but that can perform more than one function. To select a particular function you have to invoke the object and pass it a parameter or a group of parameters.
• Don’t bury your tools.
• A component is simply a set of commands that together transform data structures and algorithms into useful functions. These functions can be used without knowledge of the structures and/or algorithms within.
• By thinking about the ways in which we solve problems, apart from the problems themselves, we enrich our subconscious storehouse of techniques.
• Determine your goal.
• Picture the problem as a whole.
• Develop a plan.
• Set a course for action and avoid the trap of fumbling about aimlessly.
• Think of an analogous problem.
• Work forward.
• Work backward.
• Belief is a necessary ingredient for successfully working backward.
• Recognize the auxiliary problem.
• Step back from the problem.
• It’s easy to get so emotionally attached to one particular solution that we forget to keep an open mind.
• Use whole-brain thinking.
• When a problem has you stumped and you seem to be getting nowhere, relax, stop worrying about it, perhaps even forget about it for a while.
• Creative people have always noted that their best ideas seem to come out of the blue, in bed or in the shower.
• Evaluate your solutions. Look for other solutions.
• Don’t invest too much effort in your first solution without asking yourself for a second opinion.
• The human mind works exceptionally well with analogies.
• Each definition should perform a simple, well-defined task.
• In designing a component, the goal is to create a lexicon that will make your later code readable and easy to maintain.
• Let numbers precede names.
• Let text follow names.
• Let definitions consume their arguments.
• Use zero-relative numbering.
• Since computers are numeric processors, software becomes easier to write when we use zero-relative numbering.
• Let addresses precede counts.
• Let sources precede destinations.
• Avoid expectations (in the input stream).
• Let commands perform themselves.
• Don’t write your own interpreter/compiler when you can use Forth’s.
• A simple solution is one that does not obscure the problem with irrelevancies.
• An algorithm is a procedure, described as a finite number of rules, for accomplishing a certain task. The rules must be unambiguous and guaranteed to terminate after a finite number of applications.
• A data structure is an arrangement of data or locations for data, organized especially to match the problem.
• We’ve stated before that the best solution to a problem is the simplest adequate one; for any problem we should strive for the simplest approach.
• In choosing which approach to apply towards solving a problem, give preference in the following order: calculation, data structures, logic.
• In devising an algorithm, consider exceptions last. In writing code, handle exceptions first.
• In Forth we try to minimize our dependent on logic.
• If you have trouble thinking about a conceptual model, visualize it--or draw it--as a mechanical device.
• Good organization has three aspects: decomposition, composition, disk partitioning.
• Composition is the putting together of pieces to create a whole. Good composition requires as much artistry as good decomposition.
• Structure your application listing like a book: hierarchically.
• Modularity of the source code is one of the reasons for Forth’s quick turnaround time for editing, loading, and testing (necessary for the iterative approach).
• Begin all definitions at the left edge of the screen, and define only one word per line.
• Spacing and indentation are essential for readability.
• Every colon or code definition that consumes and/or returns any arguments on the stack must include a stack-effect comment.
• The purpose of commenting is to allow a reader of your code to easily determine what’s going on.
• Design your application so that the code, not the comments, conveys the meaning.
• The most-accurate, least-expensive documentation is self-documenting code.
• Choose names according to “what”, not “how”.
• Find the most expressive word.
• Spell names in full.
• Favor short words.
• Hyphenated names may be a sign of bad factoring.
• Don’t bundle numbers into names.
• Use prefixes and suffixes to differentiate between like words rather than to cram details of meaning into the name itself.
• Maintainability requires readability.
• Factoring means organizing code into useful fragments.
• Don’t pass control flags downward.
• If a series of definitions contains identical functions, with variation only in data, use a defining word.
• Keep definitions short.
• A word should be a line long. That’s the target.
• Factor at the point where you feel unsure about your code (where complexity approaches the conscious limit).
• Factor at the point where a comment seems necessary.
• Limit repetition of code.
• When factoring out duplicate code, make sure the factored code serves a single purpose.
• Look for repetition of patterns.
• Be sure you can name what you factor.
• If you have a concept that you can’t assign a single name to, not a hyphenated name, but a name, it’s not a well-formed concept. The ability to assign a name is a necessary part of decomposition.
• Simplify the command interface by reducing the number of commands.
• For maximum maintainability, limit redundancy even at compile time.
• Work on only one aspect of a problem at a time.
• By concentrating on one dimension of the problem at a time, you can solve each dimension more efficiently.
• Don’t change too much at once.
• Don’t try to anticipate ways to factor too early.
• Building levels of abstraction is a dynamic process, not one you can predict.
• Today, make it work. Tomorrow, optimize it.
• A good programmer continually tries to balance the expense of building-in changeability against the expense of changing things later if necessary.
• Anticipate things-that-may-change by organizing information, not by adding complexity. Add complexity only as necessary to make the current iteration work.
• Forth handles data in one of two ways: either on the stack or in data structures.
• The simplest way for Forth words to pass arguments to each other is via the stack.
• Simplify code by using the stack. But don’t stack too deeply within any single definition. Redesign, or, as a last resort, use a named variable.
• Generally, three elements on the stack is the most you can manage within a single definition.
• Especially in the design phase, keep on the stack only the arguments you’re using immediately. Create local variables for any others. (If necessary, eliminate the variables during the optimization phase.)
• When determining which arguments to handle via data structures rather than via the stack, chose the arguments that are the more permanent or that represent a current state.
• Make sure that stack effects balance out under all possible control flows.
• When doing two things with the same number, perform the function that will go underneath first.
• Where possible, keep the number of return arguments the same in all possible cases.
• Keep return stack operators symmetrical.
• Unless it involves cluttering up the stack to the point of unreadability, try to pass arguments via the stack rather than pulling them out of variables.
• Most of the modularity of Forth comes from designing and treating Forth words as “functions” in the mathematical sense.
• The return stack is a component of the Forth system designed to hold return addresses, and thereby serve as an indication of where you’ve been and where you’re going.
• When the application requires handling a group of conditions simultaneously, use a state table, not seperate variables.
• A CONSTANT’s value should never be changed once the application is compiled.
• Using the stack is preferable for testing and reusability, but too many values manipulated on the stack by a single definition hurts readability and writability.
• Control structures aren’t as important in Forth as they are in other languages.
• The use of conditional structures adds complexity to your code.
• The more complex your code is, the harder it will be for you to read and to maintain.
• Give each function its own definition.
• The Forth dictionary is a giant string case statement. The match and execute functions are hidden within the Forth system.
• Don’t test for something that has already been excluded.
• When multiple conditions have dissimilar weights (in likelihood or calculation time) nest conditionals with the term that is least likely to be true or easiest to calculate on the outside.
• The most elegant code is that which most closely matches the problem. Choose the control structure that most closely matches the control-flow problem.
• Don’t decide, calculate.
• Many times conditional control structures are applied mistakenly to situations in which the difference in outcome results from a difference in numbers.
• A trick is simply taking advantage of certain properties of operation.
• The use of tricks becomes dangerous when a trick depends on something likely to change, or when the thing it depends on is not protected by information hiding.
• Use decision tables.
• A decision table is clearly a better choice than a conditional structure when the problem has multiple dimensions.
• One change at the bottom can save ten decisions at the top.
• Don’t test for something that can’t possible happen.
• Reexamine the algorithm.
• A lot of conditionals arise from fuzzy thinking about the problem.
• Avoid the need for special handling.
• Use the structured exit.
• Fooling with the return stack is like playing with fire. You can get burned.
• Take the action when you know you need to, not later.
• Don’t put off till run time what you can compile today.
• Any time you can make a decision prior to compiling an application, do.
• The use of logic and conditionals as a significant structural element in programming leads to overly-complicated, difficult-to-maintain, and inefficient code.
• Most people go out and attack problems with complicated tools. But simpler tools are available and more useful.
• Forth is expressed in words (and numbers) and is separated by spaces.
• All words, whether included with the system or user-defined, exist in the “dictionary”, a linked list.
• Writing a Forth application consists of building increasingly powerful definitions in terms of previously defined ones.

WEAPONIZED LIES by Daniel J. Levitin

• There are not two sides to a story when one side is a lie.
• Truth matters. A post-truth era is an era of willful irrationality, reversing all the great advances humankind has made.
• Our information infrastructure is powerful. It can do good or it can do harm. And each of us needs to know how to separate the two.
• We are fortunate to have a free press; historically, most nations have had much worse. We should never take the media’s freedom and integrity for granted.
• We are a social species, and we tend to believe what others tell us.
• Some claims might be true, but truthful claims are true.
• Critical thinking trains us to take a step back, to evaluate facts and form evidence-based conclusions.
• The most important component of the best critical thinking that is lacking in our society today is humility. It is a simple yet profound notion: If we realize we don’t know everything, we can learn. If we think we know everything, learning is impossible.
• Misinformation is devilishly entwined on the Internet with real information, making the two difficult to separate.
• The unique problem we face today is that misinformation has proliferated and lies can be weaponized to produce social and political ends we would otherwise be safeguarded against.
• Critical thinking doesn’t mean we disparage everything; it means that we try to distinguish between claims with evidence and those without.
• Just because a statistic is cited doesn’t mean it’s relevant to the point at hand.
• Infoliteracy means being able to recognize that there are hierarchies in source quality, that pseudo-facts can easily masquerade as facts, and biases can distort the information we are being asked to consider, leading us to bad decisions and bad results.
• Statistics are not facts. They are interpretations.
• Sometimes, the numbers are simply wrong, and it’s often easiest to start out by conducting some quick plausibility checks. After that, even if the numbers pass plausibility, three kinds of errors can lead you to believe things that aren’t so: how the numbers were collected, how they were interpreted, and how they were presented graphically.
• Don’t just accept a claim at face value; work through it a bit.
• The cardinal rule of a pie chart is that the percentages have to add up to 100.
• An average can be a helpful summary statistic, even easier to digest than a pie chart, allowing us to characterize a very large amount of information with a single number.
• There are three ways of calculating an average, and they often yield different numbers, so people with statistical acumen usually avoid the word average in favor of the more precise terms mean, median, and mode.
• Remember, the point of an average is to be able to represent a whole lot of data with a single number.
• This is the problem with the mean: It is sensitive to outliers.
• In criminal trials, the way the information is presented—the framing—profoundly affects jurors’ conclusions about guilt.
• Be careful of averages and how they’re applied. One way that they can fool you is if the average combines samples from disparate populations.
• Also be careful to remember that the average doesn’t tell you anything about the range.
• The average can smear across differences that are important.
• The ecological fallacy occurs when we make inferences about an individual based on aggregate data (such as a group mean), and the exception fallacy occurs when we make inferences about a group based on knowledge of a few exceptional individuals.
• The human brain did not evolve to process large amounts of numerical data presented as text; instead, our eyes look for patterns in data that are visually displayed.
• Graphs come in two broad types: Either they represent every data point visually (as in a scatter plot) or they implement a form of data reduction in which we summarize the data, looking, for example, only at means or medians.
• There are many ways that graphs can be used to manipulate, distort, and misrepresent data.
• The most fundamental way to lie with a statistical graph is to not label the axes. If your axes aren’t labeled, you can draw or plot anything you want!
• A well-designed graph clearly shows you the relevant end points of a continuum. This is especially important if you’re documenting some actual or projected change in a quantity, and you want your readers to draw the right conclusions.
• When you have a situation of steady growth (or decline), the most accurate way to represent the data is on a logarithmic scale. The logarithmic scale allows equal percentage changes to be represented by equal distances on the y-axis.
• The graph maker can get away with all kinds of lies simply armed with the knowledge that most readers will not look at the graph very closely.
• Correlations range from −1 to 1. A correlation of 0 means that one variable is not related to the other at all. A correlation of -1 means that as one variable goes up, the other goes down, in precise synchrony. A correlation of 1 means that as one variable goes up, the other does too, also in precise synchrony.
• Just because someone quotes you a statistic or shows you a graph, it doesn’t mean it’s relevant to the point they’re trying to make.
• When two things are related, whether or not one causes the other, statisticians call it a correlation.
• Infographics are often used by lying weasels to shape public opinion, and they rely on the fact that most people won’t study what they’ve done too carefully.
• Statistical significance tests quantify how easily pure chance can explain the results.
• Interpolation takes two data points and estimates the value that would have occurred between them if you had taken a measurement there.
• When faced with the precision of numbers, we tend to believe that they are also accurate, but this is not the same thing.
• Access is one of those words that should raise red flags when you encounter them in statistics.
• One way to lie with statistics is to compare things—datasets, populations, types of products—that are different from one another, and pretend that they’re not.
• Be on the lookout for changing samples before drawing conclusions!
• Amalgamating is putting things that are different (heterogeneous) into the same bin or category—a
• Just because there’s a number on it, it doesn’t mean that the number was arrived at properly.
• To be any good, a sample has to be representative. A sample is representative if every person or thing in the group you’re studying has an equally likely chance of being chosen. If not, your sample is biased.
• Achieving an unbiased sample isn’t easy. When hearing a new statistic, ask, “What biases might have crept in during the sampling?”
• Margin of error and confidence interval apply to sampling of any kind,
• you can lie with statistics very easily by failing to report the margin of error or confidence interval.
• If you simply can’t reach some segment of the population, such as military personnel stationed overseas, or the homeless and institutionalized, this sampling bias is called coverage error because some members of the population from which you want to sample cannot be reached and therefore have no chance of being selected.
• People sometimes lie when asked their opinions.
• People don’t always tell the truth in surveys.
• Measurements must be standardized. There must be clear, replicable, and precise procedures for collecting data so that each person who collects it does it in the same way. Each person who is counting has to count in the same way.
• Measurement error occurs in every measurement, in every scientific field.
• Measurement error turns up whenever we quantify anything.
• How something is defined or categorized can make a big difference in the statistic you end up with.
• Whenever we encounter a news story based on new research, we need to be alert to how the elements of that research have been defined. We need to judge whether they are acceptable and reasonable.
• GIGO is a famous saying coined by early computer scientists: garbage in, garbage out.
• Much of what we read should raise our suspicions.
• Probabilities allow us to quantify future events and are an important aid to rational decision making.
• We use the word probability in different ways to mean different things.
• Subjective probability is the only kind of probability that we have at our disposal in practical situations in which there is no experiment, no symmetry equation.
• One of the most important rules in probability is the multiplication rule. If two events are independent—that is, if the outcome of one does not influence the outcome of the other—you obtain the probability of both of them happening by multiplying the two probabilities together.
• The multiplication rule only applies if the events are independent of one another.
• Often when looking at statistical claims, we’re led astray by examining an entire group of random people when we really should be looking at a subgroup.
• You can calculate the probabilities using the formula for Bayes’s rule (found in the Appendix), but an easy way to visualize and compute conditional probabilities is with the fourfold table, describing all possible scenarios:
• Most of us have difficulty figuring probabilities and statistics in our heads and detecting subtle patterns in complex tables of numbers. We prefer vivid pictures, images, and stories. When making decisions, we tend to overweight such images and stories, compared to statistical information. We also tend to misunderstand or misinterpret graphics.
• Lying weasels who want to separate us from our money, or get us to vote against our own best interests, will try to snow us with pseudo-facts, confuse us with numbers that have no basis, or distract us with information that, upon closer examination, is not actually relevant. They will masquerade as experts.
• A big part of the problem here is that the human brain often makes up its mind based on emotional considerations, and then seeks to justify them. And the brain is a very powerful self-justifying machine.
• Even the smartest of us can be fooled.
• Determining the truthfulness or accuracy of a source is not always possible.
• The first thing to do when evaluating a claim by some authority is to ask who or what established their authority.
• Experts talk in two different ways, and it is vital that you know how to tell these apart. In the first way, they review facts and evidence, synthesizing them and forming a conclusion based on the evidence. Along the way, they share with you what the evidence is, why it’s relevant, and how it helped them to form their conclusion.
• The second way experts talk is to just share their opinions. They are human. Like the rest of us, they can be given to stories, to spinning loose threads of their own introspections, what-ifs, and untested ideas.
• The term expert is normally reserved for people who have undertaken special training, devoted a large amount of time to developing their expertise (e.g., MDs, airline pilots, musicians, or athletes), and whose abilities or knowledge are considered high relative to others’. As such, expertise is a social judgment—we’re comparing one person’s skill to the skill level of other people in the world. Expertise is relative.
• Expertise also falls along a continuum.
• Experts are often licensed, or hold advanced degrees, or are recognized by other authorities.
• Some publications are more likely to consult true experts than others, and there exists a hierarchy of information sources. Some sources are simply more consistently reliable than others.
• Reputable sources want to be certain of facts before publishing them.
• As with graphs and statistics, we don’t want to blindly believe everything we encounter from a good source, nor do we want to automatically reject everything from a questionable source.
• People are not always who they appear to be on the Web.
• Knowing the domain name is helpful but hardly a foolproof verification system.
• Truth is the default position and we assume others are being truthful with us.
• When judging an expert, keep in mind that experts can be biased without even realizing it.
• A meta-analysis is a research technique whereby the results of dozens or hundreds of studies from different labs are analyzed together to determine the weight of evidence supporting a particular claim.
• A special Google search allows you to see who else links to a web page you land on. Type “link:” followed by the website URL, and Google will return all the sites that link to it.
• Peer review is not the only system to rely on, but it provides a good foundation in helping us to draw our own conclusions, and like democracy, it’s the best such system we have.
• On the Web, there is no central authority to prevent people from making claims that are untrue, no way to shut down an offending site other than going through the costly procedure of obtaining a court injunction.
• One way to fool people into thinking that you’re really knowledgeable is to find knowledgeable-sounding things on other people’s Web pages and post them to your own.
• Unscrupulous hucksters count on the fact that most people don’t bother reading footnotes or tracking down citations. This makes it really easy to lie.
• When evaluating evidence, people often ignore the numbers and axis labels, as we’ve seen, but they also often ignore the verbal descriptors, too.
• When evaluating a claim or argument, ask yourself if there is another reason—other than the one offered—that could account for the facts or observations that have been reported. There are always alternative explanations; our job is to weigh them against the one(s) offered and determine whether the person drawing the conclusion has drawn the most obvious or likely one.
• People who try to predict the future without using psychic powers—military leaders, economists, business strategists—are often wildly off in their predictions because they fail to consider alternative explanations.
• Alternative explanations are often critical to legal arguments in criminal trials.
• Our brains are built to make stories as they take in the vastness of the world with billions of events happening every second. There are apt to be some coincidences that don’t really mean anything.
• But if you’re looking only for supporting evidence, you’re not doing proper research, because you’re ignoring the contradictory evidence—there might be a little of this or a lot, but you don’t know because you haven’t looked. Colloquially, scientists call this “cherry-picking” the data that suit your hypothesis.
• Proper research demands that you keep an open mind about any issue, and try to valiantly consider the evidence for and against, and then form an evidence-based (not a “gee, I wish this were so”–based) conclusion.
• A companion to the cherry-picking bias is selective windowing. This occurs when the information you have access to is unrepresentative of the whole.
• When looking at data or evidence to support a claim, ask yourself if what you’re being shown is likely to be representative of the whole picture.
• Small samples are usually not representative.
• Larger samples more accurately reflect the state of the world. Statisticians call this the law of large numbers.
• When evaluating claims based on probabilities, try to understand the underlying model.
• Counterknowledge, a term coined by the U.K. journalist Damian Thompson, is misinformation packaged to look like fact and that some critical mass of people believes.
• Counterknowledge initially attracts us with the patina of knowledge and authority, but further examination shows that these have no basis in fact—the purveyors of counterknowledge are hoping you’ll be sufficiently impressed (or intimidated) by the presence of gritty assertions and numbers that you’ll blindly accept them.
• It’s important to accept that in complex events, not everything is explainable, because not everything was observed or reported.
• A handful of unexplained anomalies does not discredit or undermine a well-established theory that is based on thousands of pieces of evidence.
• The difference between a false theory and a true theory is one of probability.
• Absolute certainty in most news stories and scientific findings doesn’t exist. But as humans, we seek certainty. Demagogues, dictators, cults, and even some religions offer it—a false certainty—that many find irresistible.
• We assume that newspaper space given to crime reporting is a measure of crime rate.
• Cognitive psychologist Paul Slovic showed that people dramatically overweight the relative risks of things that receive media attention.
• Misunderstandings of risk can lead us to ignore or discount evidence we could use to protect ourselves.
• The main reason why so many people are dying of cancer is that they’re not dying of other things first. You have to die of something
• If you want to snow people with counterknowledge, one effective technique is to get a whole bunch of verifiable facts right and then add only one or two that are untrue.
• The fact is that bottled water is at best no safer or healthier than most tap water in developed countries, and in some cases less safe because of laxer regulations.
• The development of critical thinking over many centuries led to a paradigm shift in human thought and history: the scientific revolution.
• The search for proof, for certainty, drives science, but it also drives our sense of justice and all our judicial systems. Scientific practice has shown us the right way to proceed with this search.
• There are two pervasive myths about how science is done. The first is that science is neat and tidy, that scientists never disagree about anything. The second is that a single experiment tells us all we need to know about a phenomenon, that science moves forward in leaps and bounds after every experiment is published.
• Real science is replete with controversy, doubts, and debates about what we really know.
• Real scientific knowledge is gradually established through many replications and converging findings.
• Scientific progress depends on two kinds of reasoning.
• In deduction, we reason from the general to the specific, and if we follow the rules of logic, we can be certain of our conclusion.
• In induction, we take a set of observations or facts, and try to come up with a general principle that can account for them. This is reasoning from the specific to the general.
• In abductive reasoning, we start with a set of observations and then generate a theory that accounts for them. Of the infinity of different theories that could account for something, we seek the most likely.
• The brain is a giant pattern detector, and it seeks to extract order and structure from what often appear to be random configurations.
• An odd feature of human cognition is that once we form a belief or accept a claim, it’s very hard for us to let go, even in the face of overwhelming evidence and scientific proof to the contrary.
• A properly formulated scientific hypothesis is falsifiable—there are steps we can take, at least in theory, to test the true state of the world, to determine if our hypothesis is true or not. In practice, this means considering alternative explanations ahead of time, before conducting the experiment, and designing the experiment so that the alternatives are ruled out.
• The unknown unknowns are the most dangerous.
• One of the main purposes of training someone for a PhD, a law or medical degree, an MBA, or military leadership is to teach them to identify and think systematically about what they don’t know, to turn unknown unknowns into known unknowns.
• One of the biggest causes of bad, even fatal, outcomes is belief in things that are untrue.
• Using Bayes’s rule allows us to combine objective probabilities,
• Critical thinking is something that can be taught, and practiced, and honed as a skill.
• There is an infinite variety of ways that faulty reasoning and misinformation can sneak up on us. Our brains weren’t built to excel at this.
• It sounds counterintuitive, but it’s true: Not all treatments actually help.
• If you want to convince people of something that’s not true, it’s apparently very effective to simply snow them with one question after another, and hope that they will be sufficiently impressed—and overwhelmed—that they won’t bother to look for explanations.
• Professional magicians typically calculate and plan everything they say. Every single move, every apparently spontaneous scratch of the head, is typically rehearsed over and over again.
• A lot of what magicians practice over and over again is getting the audience to accept things that are a bit out of the ordinary.
• Expertise tends to be narrow.
• The scientific method is the ground from which all the best critical thinking rises.
• Critical thinking is not something you do once with an issue and then drop it. It’s an active and ongoing process. It requires that we all think like Bayesians, updating our knowledge as new information comes in.
• We’re far better off knowing a moderate number of things with certainty than a large number of things that might not be so.