Entailment: downward and upward
Contents
A. Introduction 2
1. The computational turn 3
2. Software developers stand on firmer foundations than engineers 3
3. What this paper is about 4
B. Emergence 5
1. Abstractions and implementations 6
2. Emergence and software 10
3. Strong emergence 11
4. Emergence summary 13
C. The special sciences 14
1. The special sciences and conceptual models 14
2. More about why there is something besides physics 16
3. Do the laws of physics entail all other laws? 20
4. Summary position on the special sciences 26
D. Reduction, upward entailment, and downward entailment 26
1. Reduction (and explanation?) 26
2. Upward entailment 28
3. Downward entailment 28
E. Downward causality and downward entailment 29
1. Introduction to downward causation 29
2. A better way to look at downward causation 34
F. What have we said? 42
References (some of the following are not cited and should be removed) 42
Appendix 1: An introduction to higher level entities 48
Appendix 2: The first two definitions of causality in Ellis (2012) 49
Abstract. There is near universal agreement that the fundamental laws of physics are sufficient to explain all observed phenomena—i.e., that nature is causally closed. Downward (or top-down) causation does not fit within this paradigm. Yet like a zombie idea, it refuses to die. After reviewing basic issues pertaining to causality, emergence, and the autonomy of the laws of the special sciences, I argue that the apparent paradox is overblown and appears to be the result of confusing analysis and synthesis. I explain why emergence and the special sciences are central to understanding how the world works and why the laws of the special sciences are autonomous. A key idea is that the special sciences characterize domains that are autonomous in their functioning but limited by the requirement that they be implemented within a world governed by physics. An examination of how a modern-day Laplacian demon also demonstrates the need for the special sciences. A simple and clear-cut example (from outside the realm of physics) is that the Theory of Computability is autonomous of the rules governing the Game of Life. Yet it is possible to implement a Turing machine (as an emergent phenomenon) on a Game-of-Life grid. Furthermore, the possibility of that implementation entails the undecidability of the halting problem for the Game of Life, thereby illustrating downward entailment—but not downward causation. Methodologically this paper shows how modes of thinking from computer science can apply to problems in philosophy, thereby illustrating “the computational turn.”
A. Introduction
Question: what do emergence, downward causation, and the relationship between physics and the special sciences have in common?
Answer: the multi-level mystery.
Fodor (1997) famously put the special sciences version of the multi-level mystery like this.
The very existence of the special sciences testifies to reliable macro-level regularities that are realized by mechanisms whose physical substance is quite typically heterogeneous. Does anybody really doubt that mountains are made of all sorts of stuff? Does anybody really think that, since they are, generalizations about mountains-as-such won't continue to serve geology in good stead? Damn near everything we know about the world suggests that unimaginably complicated to-ings and fro-ings of bits and pieces at the extreme micro-level manage somehow to converge on stable macro-level properties.
On the other hand, the 'somehow' really is entirely mysterious. [Why should there be (how could there be)] macro-level regularities at all in a world where, by common consent, macro-level stabilities have to supervene on a buzzing, blooming confusion of micro-level interactions? …
So, then, why is there anything except physics? … Well, I admit that I don't know why. I don't even know how to think about why. I expect to figure out why there isanything except physicsthe day before I figure out why there is anything at all. …
The world, it seems, runs in parallel, at many levels of description. You may find that perplexing; you certainly aren’t obliged to like it. But I do think we had all better learn to live with it.
I am not a professional philosopher. My PhD is in Computer Science, and I teach in a Department of Computer Science.[1] I don’t find a world that runs on many level perplexing, and I don’t not like it. In fact, I like it a lot. In this paper I’ll explain why—and why that might be of interest to philosophers.
1. The computational turn
The International Association for Computing and Philosophy (IACAP) defines its mission as promoting “scholarly dialogue on all aspects of the computational/informational turn and the use of computers in the service of philosophy.”[2] What is the “computational turn?” My sense is that it has to do with how we computer scientists tend to think.
Well, how do we think? Overwhelmingly the task of software development is to create new abstractions and then implement those abstractions as software by putting together already implemented software abstractions. An example familiar to nearly everyone is a word processing program such as Microsoft Word.[3] Word processors offer users the ability to create and manipulate documents. They offer this capability my making available the use and manipulation of abstractions such as words, paragraphs, footnotes, sections, etc.
A software developer has two important tasks. One is to understand and to clarify what the important abstractions are in a domain—i.e., how the potential users of her software-to-be thinks. The second task is to write software that implements those abstractions and gives those potential users access to operations on them. These implementations are created by putting together existing abstractions such as those defined by programming languages and software libraries.
2. Software developers stand on firmer foundations than engineers
Much of what I said about creating and implementing abstractions applies to engineers as well as to software developers. Engineers, too, create products that embody new abstractions and functionalities. And they do it by putting together components that provide existing abstractions. “Smart” phones offer many examples. A nice one is the smart phone’s ability to re-orient its display (portrait or landscape) depending on how the phone is held. How do engineers get phones to do that? They use a pre-existing device, the small-scale accelerometer, which had been developed for and has a wide range of uses in industrial and commercial products. One of its more familiar uses is in game controllers such as the Nintendo Wii. An accelerometer in a game controller can tell the software in the controller about the user’s motion. When the user swings her arm as if holding a tennis racket, the controller can display a picture of someone swinging a racket in a way that parallels the user’s movements. In a smart phone, the accelerometer is used much more simply—to let the software in the phone know how the phone was moved and how it is oriented. The point is that a device whose functionality had been used for one purpose is now used for another.
Software developers have an important advantage over engineers.[4] We need not be concerned about the reliability of our primitives. The lowest level software element is the bit. It is an atomic ideal. It cannot be decomposed into smaller elements, and it cannot wear out. As far as software developers are concerned, bits are forever; you can’t break a bit. Engineers have no such solid foundation. When building something they must always be concerned about whether the components are appropriate for the application of the device. This is not a trivial issue; there is no a priori limit to the depth of analysis required to provide the assurance that the components will work when the device is put to use. For example, there are many different types of accelerometers. Some are quite rugged; others fail when not in a laboratory environment. In addition, there is trade-off between accelerometer size and sensitivity. Larger accelerometers are better at sensing smaller movements, but heavier mobile phones don’t sell as well. For example, see (Lally, 2005). Issues of these sorts require engineers always to be looking down toward the physical foundations of the devices they use as well as up toward the new abstractions they are building. Only software developers and God[5] can be secure in the certainty of their knowledge of the fundamental elements of their universes. (See (Abbott, 2010a) for additional discussion.)
3. What this paper is about
Because our job is the creation and implementation of abstractions, we software developers are typically skilled in understanding both (a)what it means to define new levels of abstraction and (b)what it takes (and whether it is even possible) to implement those new abstractions in terms of existing abstractions. Because we do this work in a world with an indestructible primitive, we are free of worries about the strength of our foundations and can focus exclusively on abstractions and relationships among them.
One of my goals in this paper is to apply our approach to creating and embodying abstractions to philosophical issues. In particular, I’ll explore abstraction and implementation in emergence, in the special sciences, and in downward causation.[6] I’ll also have a number of other things to say about these areas. In particular, I’ll be dismissive of strong emergence—and eventually of emergence in general. I’ll propose a way of settling the debate about whether the laws of physics entail the laws of the special sciences, and I’ll suggest downward entailment as a better conceptual framework than downward causation for understanding some of the apparent consequences of the multi-level mystery.
A disclaimer: although the multi-level mystery is often associated with the theory of mind, this paper is not about mind or consciousness. I don’t believe we know enough about consciousness to be able to say anything useful about it—other than that it’s a puzzle we have hardly begun to unravel.
B. Abstractions and implementations in computer science
As background for the rest of this paper, I want to spend a brief time reviewing abstraction and implementation in computer science.
1. Computer programs: what people in my field work with
For those of us who spend our professional lives in the field of computing, the primary object of study is the computer program. I had a hard time writing that sentence because the term computer program sounds like it describes such a pedestrian object, hardly a work of intellectual depth and sophistication. I could have written software, but that’s no better. Yet it is computer programs that we deal with, both as developers and theorists.
Theoretical computer scientists—those who study computability—may talk about Turing machines, but since any Turing machine can be understood as a program to be executed by a universal Turing machine, a Turing machine is really just a computer program. The same can be said about those who study the λ-calculus and related formalisms. These too are really programming languages—which allow one to write computer programs, which can be run on λ-calculus abstract machines. So we are stuck with the fact that computer scientists study computer programs.
2. Computer programs have both a static and dynamic aspect
Computer programs must be understood from two perspectives: as a static expression of a computation and as the dynamic process that is the described computation. Issues related to programs as static objects derive from their status as expressions in a language. The semantics of a programming language determines what one can say about the process a program describes. The primary issues involve (a)control structures (what one can say about how the process proceeds), (b)data types and data structures (what one can say about the elements the process operates on), and (c)modularity (the ways in which the language allows programs to be decomposed into what will be interacting dynamic components.[7])
Issues related to programs as dynamic processes span the range from theory to practicality. There are theoretical questions such as whether the program-as-process will ever terminate. There are questions that are both theoretical and practical such as how long (as a function of the size of the input) the program-as-process will take to terminate—assuming we know that it will. There are abstract questions such as how to describe the dynamic structure of the program-as-process as it runs. And there are more practical questions such as what will it be like for the program-as-process to interact with the rest of the world, including both the people it may encounter and devices the it may monitor and control.
Computer science is not the only discipline whose products have significant static and dynamic aspects. Others include music, theater, film, and many (perhaps most) engineering specializations. For them as for us what is generally produced is a static product (a)whose static properties are important but (b)whose primary value is as a dynamic process. Even though people in these fields spend most of their time producing static objects—a computer program, a script, an automobile, a computer, etc.—the primary value in those static objects inheres in their performance as a process.
This is an especially important point to keep in mind about computer programs. Since the static products we produce are symbolic, it’s easy to ignore their dynamic aspects and to imagine that their static properties are their most important features. To do so would be a mistake. As symbolic objects, computer programs may look like mathematical objects; it is even possible to analyze computer programs as mathematical objects; but what’s most important about computer programs is that they describe processes. These processes occur in time and do something in the world—namely, they perform computations.