Programs for Philosophical Simulations and Experiments Robert L. Causey Department of Philosophy The University of Texas at Austin Austin, Texas 78712 8 March 1987 This document is derived from: Robert L. Causey, ``Philosophical Simulations and Experiments: Scientific Reasoning Processes''. In F. D. Dwyer, et al, eds., PROCEEDINGS OF THE 1986 UNIVERSITY AEP CONFERENCE, IBM Academic Information Systems, Milford, Connecticut (1986). A more detailed description of the programs is forthcoming in ``Simulations and Experiments in Philosophy of Science'' in PERSPECTIVES IN COMPUTING, IBM , Spring 1987. 1. Educational Goals of These Programs Early Computer Assisted Instruction (CAI) programs largely relied on drill and practice training. Although CAI and related computer-based tutoring systems have significant educational roles, there are other effective, instructional uses of computers. For instance, computers can be used to produce demonstrations that simulate processes or exhibit complex calculations in effective, graphical format. These demonstrations can be run by individual students, or by the instructor during a lecture. One of the main concerns of philosophy of science is the analysis and codification of various types of scientific reasoning processes. There has been special interest in the general logical structure of scientific explanations, and how the construction of such explanations depends on hypothesis formation and testing. Although almost all undergraduates take some laboratory courses, most of them (including science majors) do not experience the frustrations and joys of creating their own original hypotheses and explanations. Teaching philosophy of science to advanced undergraduates and beginning graduate students is therefore hindered by their lack of experience with novel scientific problem situations and the reasoning processes required to solve them. The principal aim of these programs is to use the computer to provide this kind of experience and motivate serious reflection about it. 2. Instructional Use of the Simulations A typical computer simulation models some possible real-world system. Philosophers do not usually perform laboratory experiments, although our work constantly involves thought experiments. It is possible to design a number of useful simulations of abstract relationships and operations. The aim of these programs is to give students experience with scientific problem-solving reasoning. Accordingly, the computer is used to simulate small, generic, scientific research problems. The two programs are described in more detail in the next section: each program simulates, in terms of colors and geometric shapes, various ``worlds'' or ``systems'' which the student investigates. The first program, INDUCT, repeatedly presents nearly-random color patterns in which the randomness is only partially overridden by constraining laws. The student is required to discover, and confirm by experiment, the governing laws. The second program, FAST, presents an abstract system with a few parts. The parts are geometric shapes which can have different colors. The systems (which can be interpreted as factories, biological organisms, etc.) accept an input and produce various outputs, which are also colored geometric shapes. Students working with FAST are presented with the problem of discovering and explaining the functional organization of such systems. In the case of both programs, the student invents hypotheses to explain the observations and also interactively performs experiments to test his or her hypotheses. The student is required to maintain a paper record of his experiments. Finally, the student writes a short research report which both describes the ``experimental research'' and ``explanatory theory'', and which also discusses philosophical questions about the research methodology. Since there is not sufficient time to perform exhaustive tests of the hypotheses, the student cannot be sure that he or she has found the ``correct'' solution. As a result of all of this, the student acquires experience with: - Inductive reasoning and hypothesis formation - Design of experimental tests of hypotheses - Construction of scientific explanations - The doubts connected with scientific hypotheses and explanations - Philosophical analysis of scientific reasoning - Writing of scientific reports and philosophical discussion 3. Design and Use of the Programs The two programs on this disk, INDUCT and FAST, were written in TM Microsoft BASICA and converted into executable code using Microsoft's BASIC Compiler (Version 1.00) and Linker (Version 1.10). [They can also be compiled with the newer MS QuickBasic compiler.] The source codes are in the files INDUCT.BAS and FAST.BAS, and the stand-alone executable code is in INDUCT.EXE and FAST.EXE, respectively. The compiled programs are easy for the students to run and satisfy the requirement that the students TM cannot read the code. The programs run on IBM PC's, XT's, and AT's with a color monitor and color graphics adapter board. With no modifications, the compiled programs have run on DOS Versions TM 2.0 and higher, and on an IBM-compatible computer using MS-DOS 3.1. 3.1. The INDUCT Program At start up the student is told that there are several different worlds, identified only by numbers. The student is asked to choose a world by number. World # 1 is reserved for an introductory classroom demonstration that I show the students before they begin their interactive work. After a world is selected, the monitor screen will display a black background and an outline of 16 squares. Although not shown in the display, each square is identified by an ordered-pair of coordinate numbers; the students refer to a chart (which I draw) showing these coordinates. The coordinates are (x,y), where x is the column number and y is the row number, starting with (1,1) for the upper left square. When the program calls a particular display, the squares are colored white, pink, or blue, starting with square (1,1), then to (2,1), (3,1), (4,1), (1,2), etc., down to the (4,4) square. New displays can be generated indefinitely, simply by hitting the carriage return key. Each new display has a color pattern which is produced almost at random. Yet, depending on the particular world chosen, there will be one or more ``laws'' that relate the colors of some squares to the colors of some other squares. At the beginning of each cycle of the infinite loop, a RANDOMIZE COLORS routine generates color codes for each square of the display matrix; a given square is assigned one of the three colors at random. These codes are stored in an internal array in memory; the pattern is not displayed at this point. If the student hits the carriage return, an INVOKE LAWS routine is called. If the antecedent of a law is satisfied by the color codes stored in the internal array, then this law exerts its effect and the color codes of the array are adjusted in accordance with the consequent clause of the law. A trivial example is the law that states: IF PINK (1,1), THEN BLUE (4,4). If the array element for square (1,1) has the code for Pink, then this law will set square (4,4) to Blue, regardless of what color (4,4) may have been assigned by the RANDOMIZE COLORS routine. Since the laws of a particular world are just lines of BASIC statements, they are tested for possible firing in the order that they occur in the program. This flow-of-control limitation has the advantage of simulating a simple ``causal direction'' in the abstract color worlds. At the bottom of each display the user is prompted for the next action. By pressing the carriage return key (), the student observes the repeatedly displayed patterns for some time, making notes of what seem to be significant patterns. Eventually, by an inductive reasoning process, or just guesswork, the student forms an hypothesis about a possible law. At this point, he or she can perform experiments to test this hypothesis. When prompted for the next action, he chooses the Set (colors) option, and the SET COLORS routine is called. This routine permits the user to assign particular colors to any desired subset of squares. For example, to make square (2,3) Pink, the student enters ``P23''. This can be followed by any number of similar entries; after each entry, the list of assignments is displayed and may be modified. This process continues until the student is satisfied with the assignments; then the INVOKE LAWS routine is called, after which the display follows. The student can get online help by typing a question mark while in the setting routine. The help screen also describes the coordinate system in case a diagram is not available. The colors randomly assigned to squares are overridden by the student's settings before the INVOKE LAWS routine and the display routine are called. The colors assigned to specific squares by the student will be displayed, except in those cases where a square's color is subsequently changed by the activation of one or more laws. In this way the student can test his or her hypothesized laws by performing a number of experiments. I am a strong believer in the importance of writing practice, so I have the student keep a record of significant experiments, and then write a ``research paper'' describing significant hypotheses considered, how they were tested, the results that were obtained, and how these results can or cannot explain typical observations. In addition, the paper must relate this ``research work'' to more general questions about scientific methodology. 3.2. The FAST Program The INDUCT program is designed to simulate ``causal laws'' of the various color worlds. The student seeks to discover these laws and use them to make ``causal explanations'' and predictions of the observed color pattern behavior. Providing this form of deductive explanation from laws plus initial conditions is one way of gaining an understanding of a domain of phenomena. There are other ways through which we can gain scientific understanding; one of the most common of these is to develop a FUNCTIONAL DESCRIPTION or FUNCTIONAL ANALYSIS of a system. If we have a system composed of interacting parts which contribute to the overall behavior of the system, we often want to understand the functional roles of these parts and how these roles contribute to the overall ``normal behavior'' of the system. Causal and functional explanations have been extensively studied by philosophers of science; see, for instance, [Achinstein 83]. FAST (``Functional Analysis System Testing'') is designed to provide experience with functional analysis. Just as INDUCT offers the student a choice of different color worlds, FAST offers a choice of different systems (one of which is reserved for introductory class demonstrations). Each system has the same overall appearance. There is a constant input to the system, represented by the ellipse on the extreme left. Inside the system (the large rectangle), are four shapes: triangle, square, ellipse, and circle. In a particular display, all, some, and sometimes none, of these will appear. If any one of these figures does appear, it may be White, Pink, or Blue. Finally, the display may or may not exhibit a system output on the extreme right. If an output does appear, it will be an Arrow, a Rod (rod-shaped figure), or a Diamond. Outputs may also be either White, Pink, or Blue. Although these systems are quite abstract, it is convenient to describe them in familiar language. I suggest to the students that a system be interpreted as a ``factory''. Inside the factory (the large rectangle) there may be a Boss, a Molder, a Painter, and a ``Messer''. The geometric shapes corresponding to these functional positions may vary, both across different systems, and to some extent within a given system. As they are currently designed, each system has constant shapes for its Boss and its Messer. A Boss must be present in order to obtain an output. The color of the Boss determines which shapes will be the Molder and the Painter; this assignment of ``duties'' is the principal function of the Boss. In this interpretation a system's output object is the ``Product'' produced by the factory. In general, the color of the Molder determines the shape of the Product, and the color of the Painter determines the color of the Product. One exception to these generalizations is this: in certain special situations the Messer (when present) can interfere with the ``normal'' operations of the system. Before a display occurs, a randomization routine pre-selects the colors of the four system parts. In a particular display of FAST, it is also possible that a given part may not appear. In this case, we say that its ``color'' is ``Nocolor''. Actually, it is black and so is indistinguishable from the screen background. If the triangle, say, has Nocolor, then the triangle is missing from that display and therefore cannot perform its function. If the triangle happens to be the Boss, then no Product will be produced. By repeatedly pressing the carriage return key, the student can observe various combinations of parts either missing or present in particular colors. At the same time the student can observe what kinds of Products (Rod, Arrow, or Diamond), if any, result, and in what colors. The student's basic problem is to determine, for the chosen system, the rules governing the conditions under which the various shapes play the roles of Boss, Painter, Molder, or Messer, and to determine the functions of these items. The functions are also described in terms of rules: The rules for the Boss say how the color (``disposition'') of the Boss determines which shapes it selects for the Painter and Molder. The rules for the Molder state how its color determines the shape of the Product. The rules for the Painter relate its color to the color of the Product. The Messer's rules specify when and how it interferes with the operations of the other rules. Finally, a particular system usually has one or two default rules covering cases not covered by the other functional rules. These systems can be fairly complicated, even though they have only four internal parts. It is important that the instructor demonstrate to the class how to work with FAST by using System D and giving the students some hints. Thus the instructor should study the program, and in particular, the system rules near the end of the source code. FAST contains much online help for the user, but this help does not explain the methodology for solving the problems. As with INDUCT, a randomization routine pre-selects colors, or Nocolor, for each (internal) part of the system. If the student simply presses the carriage return, the rules of that particular system are called, and these rules determine the shape and color of the Product, if any. The system with its colored parts and Product (if any) is then displayed. These randomized display cycles are repeated until the student forms one or more hypotheses about the system's functional organization. At this point he or she can begin serious experimenting, by setting the colors of one or more internal shapes. The possible settings include Nocolor, which removes that part from the forthcoming display. For example, the student may set Triangle to Blue and Circle to Nocolor. Setting one or more shapes to Nocolor can help to yield evidence regarding which shapes perform essential functions and which do not. The student's settings override the randomized, pre-selected color settings before the rules are called, and then the display occurs. Unlike INDUCT, the student's settings override the randomized settings only in the cases of the particular shapes whose colors he has chosen to set. There is also an option (Keep) for retaining particular settings as long as desired, when cycling through displays with the remaining parts colored randomly. Working with FAST provides additional experience with inductive reasoning and hypothesis testing beyond that obtained from INDUCT, but FAST is especially helpful in teaching aspects of functional analysis. Although people have experience with functional descriptions in everyday life, this experience is usually not in the context of rigorous experimentation and explanation. FAST provides this rigor while the student is experimenting and when he writes his paper discussing the results. In particular, the student gains experience with - Hypothesizing the ``normal behavior'' of a system - Hypothesizing the functions of the parts of this system, and stating precisely the rules that interrelate these parts as well as their functions with respect to the overall behavior of the system - Design of experimental tests of functional hypotheses, and the limitations and doubts connected with such hypotheses - Critical analysis of the logical structure and scientific significance of functional explanations - Writing of scientific reports and philosophical discussion 4. Discussion INDUCT was written by the author during the summer and early fall of 1984. FAST was designed by the author during the spring of 1985. After the general design was worked out, a student assistant, M. J. Jewell, wrote the first version of FAST during the summer of 1985. Mr. Jewell contributed additional ideas to the overall program design and organization and described his work in an earlier report, ( [Jewell 85]). I then further revised FAST for student use. I have used both programs in several philosophy of science classes, and INDUCT has also been used by a colleague in one of his classes. Although not experienced with BASIC programming, this colleague successfully revised one of the worlds in INDUCT by changing its laws. I encourage instructors to design new sets of laws in these programs. The programs are currently being tested in some other universities. A typical student requires about two hours of computer work to ``solve'' an INDUCT world and about three hours to ``solve'' a FAST system. ``Solve'' means to do enough work to discover the laws and collect sufficient data to give a fairly strong justification for one's hypotheses. In the case of FAST, students sometimes cannot discover the MESSER's rules (and the MESSER may do nothing in some systems). For more details about the instructional use of these programs, see my forthcoming article in PERSPECTIVES IN COMPUTING. I encourage science and philosophy of science teachers to develop these programs further. Acknowledgements Part of this work, reporting on the INDUCT program, has been previously presented in [Causey 85]. I am indebted to Mr. Michael Jewell for his excellent assistance in the development of FAST. The equipment and software for this project were provided by a grant from The University of Texas Project Quest office, which in turn received a grant from the IBM Corporation. I also wish to thank my students for their hard work with the two programs, and for their useful suggestions regarding future developments. The contents of this document are not intended as an endorsement of any product. The views expressed are entirely my own and are not necessarily endorsed by any other individual or organization. REFERENCES [Achinstein 83] Achinstein, P. The Nature of Explanation. Oxford University Press, New York, N.Y., 1983. [Causey 85] Causey, R. L. Microcomputer Simulations in the Teaching of Logic and Philosophy of Science. 1985. Invited paper presented at the conference on Logic, Logic Machines, and Public Education, sponsored by The Institute for Logic and Cognitive Studies, University of Houston-Clear Lake, June 13-15, 1985. Forthcoming in the conference proceedings. [Jewell 85] Jewell, M. J. Computerized Functional Analysis Teaching System. August, 1985. Senior Thesis for the University of Texas at Austin Plan II Liberal Arts Honors Program.