1.1 Program Organization and Control Structures 7 modularization and encapsulation become important programming concepts,the general idea being that program units should interact with one another only through clearly defined and narrowly circumscribed interfaces.Good modularization practice is an essential prerequisite to the success of large,complicated software projects. especially those employing the efforts of more than one programmer.It is also good practice (if not quite as essential)in the less massive programming tasks that an individual scientist.or reader of this book.encounters Some computer languages,such as Modula-2 and C++,promote good modular- ization with higher-level language constructs absent in C.In Modula-2,for example. 三 functions,type definitions,and data structures can be encapsulated into"modules" that communicate through declared public interfaces and whose internal workings g are hidden from the rest of the program [41.In the C++language,the key concept is"class,"a user-definable generalization of data type that provides for data hiding, automatic initialization of data,memory management,dynamic typing,and operator overloading (i.e.,the user-definable extension of operators like and so as to be appropriate to operands in any particular class)[5].Properly used in defining the data 之 structures that are passed between program units,classes can clarify and circumscribe these units'public interfaces,reducing the chances of programming error and also allowing a considerable degree of compile-time and run-time error checking. 9 Beyond modularization,though depending on it,lie the concepts of object- oriented programming.Here a programming language,such as C++or Turbo Pascal 5.5 [6],allows a module's public interface to accept redefinitions of types or actions. and these redefinitions become shared all the way down through the module's hierarchy (so-called polymorphism).For example,a routine written to invert a matrix 三兰∽9 ofreal numbers could-dynamically,at run time-be made able to handle complex 心客a OF SCIENTIFIC numbers by overloading complex data types and corresponding definitions of the arithmetic operations.Additional concepts of inheritance (the ability to define a data type that"inherits"all the structure of another type,plus additional structure of its own),and object extensibility (the ability to add functionality to a module without access to its source code,e.g.,at run time),also come into play. We have not attempted to modularize,or make objects out of,the routines in this book,for at least two reasons.First,the chosen language,C,does not really make this possible.Second,we envision that you,the reader,might want to incorporate 10621 the algorithms in this book,a few at a time,into modules or objects with a structure Numerical Recipes 43106 of your own choosing.There does not exist,at present,a standard or accepted set of"classes"for scientific object-oriented computing.While we might have tried to invent such a set,doing so would have inevitably tied the algorithmic content of the 腿 book(which is its raison d'etre)to some rather specific,and perhaps haphazard,set of choices regarding class definitions. North On the other hand,we are not unfriendly to the goals of modular and object- oriented programming.Within the limits of C,we have therefore tried to structure our programs to be "object friendly."That is one reason we have adopted ANSI C with its function prototyping as our default C dialect (see $1.2).Also,within our implementation sections,we have paid particular attention to the practices of structured programming,as we now discuss.1.1 Program Organization and Control Structures 7 Permission is granted for internet users to make one paper copy for their own personal use. Further reproduction, or any copyin Copyright (C) 1988-1992 by Cambridge University Press. Programs Copyright (C) 1988-1992 by Numerical Recipes Software. Sample page from NUMERICAL RECIPES IN C: THE ART OF SCIENTIFIC COMPUTING (ISBN 0-521-43108-5) g of machine￾readable files (including this one) to any server computer, is strictly prohibited. To order Numerical Recipes books or CDROMs, visit website http://www.nr.com or call 1-800-872-7423 (North America only), or send email to directcustserv@cambridge.org (outside North America). modularization and encapsulation become important programming concepts, the general idea being that program units should interact with one another only through clearly defined and narrowly circumscribed interfaces. Good modularization practice is an essential prerequisite to the success of large, complicated software projects, especially those employing the efforts of more than one programmer. It is also good practice (if not quite as essential) in the less massive programming tasks that an individual scientist, or reader of this book, encounters. Some computer languages, such as Modula-2 and C++, promote good modular￾ization with higher-level language constructs absent in C. In Modula-2, for example, functions, type definitions, and data structures can be encapsulated into “modules” that communicate through declared public interfaces and whose internal workings are hidden from the rest of the program [4]. In the C++ language, the key concept is “class,” a user-definable generalization of data type that provides for data hiding, automatic initialization of data, memory management, dynamic typing, and operator overloading (i.e., the user-definable extension of operators like + and * so as to be appropriate to operands in any particular class) [5]. Properly used in defining the data structures that are passed between program units, classes can clarify and circumscribe these units’ public interfaces, reducing the chances of programming error and also allowing a considerable degree of compile-time and run-time error checking. Beyond modularization, though depending on it, lie the concepts of object￾oriented programming. Here a programming language, such as C++ or Turbo Pascal 5.5 [6], allows a module’s public interface to accept redefinitions of types or actions, and these redefinitions become shared all the way down through the module’s hierarchy (so-called polymorphism). For example, a routine written to invert a matrix of real numbers could — dynamically, at run time — be made able to handle complex numbers by overloading complex data types and corresponding definitions of the arithmetic operations. Additional concepts of inheritance (the ability to define a data type that “inherits” all the structure of another type, plus additional structure of its own), and object extensibility (the ability to add functionality to a module without access to its source code, e.g., at run time), also come into play. We have not attempted to modularize, or make objects out of, the routines in this book, for at least two reasons. First, the chosen language, C, does not really make this possible. Second, we envision that you, the reader, might want to incorporate the algorithms in this book, a few at a time, into modules or objects with a structure of your own choosing. There does not exist, at present, a standard or accepted set of “classes” for scientific object-oriented computing. While we might have tried to invent such a set, doing so would have inevitably tied the algorithmic content of the book (which is its raison d’etre ˆ ) to some rather specific, and perhaps haphazard, set of choices regarding class definitions. On the other hand, we are not unfriendly to the goals of modular and object￾oriented programming. Within the limits of C, we have therefore tried to structure our programs to be “object friendly.” That is one reason we have adopted ANSI C with its function prototyping as our default C dialect (see §1.2). Also, within our implementation sections, we have paid particular attention to the practices of structured programming, as we now discuss