DOCSLIB.ORG

Alexander Stepanov Notes on Programming 12/24/2018 1 Preface

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Alexander Stepanov Notes on Programming 12/24/2018 1 Preface Alexander Stepanov Notes on Programming 12/24/2018 Preface .............................................................................................................................. 2 Lecture 1. Introduction .............................................................................................. 3 Lecture 2. Designing fvector_int ....................................................................... 8 Lecture 3. Continuing with fvector_int.......................................................... 24 Lecture 4. Implementing swap .............................................................................. 36 Lecture 5. Types and type functions .................................................................. 43 Lecture 6. Regular types and equality ............................................................... 51 Lecture 7. Ordering and related algorithms .................................................... 56 Lecture 8. Order selection of up to 5 objects ................................................. 64 Lecture 9. Function objects .................................................................................... 69 Lecture 10. Generic algorithms ............................................................................ 78 10.1. Absolute value ............................................................................................. 78 10.2. Greatest common divisor ........................................................................ 83 10.2.1. Euclid’s algorithm ............................................................................... 83 10.2.2. Stein’s algorithm ................................................................................ 88 10.3. Exponentiation ............................................................................................. 94 Lecture 11. Locations and addresses ............................................................... 110 Lecture 12. Actions and their orbits ................................................................. 113 Lecture 13. Iterators ............................................................................................... 129 Lecture 14. Elementary optimizations ............................................................. 136 Lecture 15. Iterator type-functions................................................................... 139 Lecture 16. Equality of ranges and copying algorithms ........................... 139 Lecture 17. Permutation algorithms ................................................................. 139 Lecture 18. Reverse ................................................................................................ 143 Lecture 19. Rotate ................................................................................................... 154 Lecture 20. Partition ............................................................................................... 167 Lecture 21. Optimizing partition ........................................................................ 178 Lecture 22. Algorithms on Linked Iterators ................................................... 183 Lecture 23. Stable partition ................................................................................. 192 Lecture 24. Reduction and balanced reduction ............................................ 199 Lecture 25. 3-partition ........................................................................................... 207 Lecture 26. Finding the partition point ............................................................ 212 Lecture 27. Conclusions ......................................................................................... 216 1 Alexander Stepanov Notes on Programming 12/24/2018 Preface This is a selection from the notes that I have used in teaching programming courses at SGI and Adobe over the last 10 years. (Some of the material goes back even further to the courses I taught in the 80s at Polytechnic University.) The purpose of these courses was to teach experienced engineers to design better interfaces and reason about code. In general, the book presupposes a certain fluency in computer science and some familiarity with C++. This book does not present a scholarly consensus. It presents my personal opinions and should, therefore, be taken with a grain of salt. Programming is a wonderful activity that goes well beyond the range of what a single programmer can experience in a lifetime. This is not a book about C++. Although it uses C++ and would be difficult to write the focus is on programming rather than programming language. This is not a book about STL. I often refer to STL as a source of examples both good and (more often than I would like) bad. This book will not help one become a fluent user of STL, but it explains the principles used to design STL. This book does not attempt to solve complicated problems. It will attempt to solve very simple problems which most people find trivial: minimum and maximum, linear search and swap. These problems are not, however, as simple as they seem. I have been forced to go back and revisit my view of them many times. And I am not alone. I often have to argue about different aspects of the interface and implementation of such simple functions with my old friends and collaborators. There is more to it, than many people think. I do understand that most people have to design systems somewhat more complex than maximum and minimum. But I urge them to consider the following: unless they can design a three line program well, why would they be able to design a three hundred thousand line program. We have to build our design skills by following through simple exercises, the way a pianist has to work through simple finger exercises before attempting to play a complicated piece. This book would never have been written without the constant encouragement of Sean Parent, who has been my manager for the last three years. Paul McJones and Mark Ruzon had been reviewing every single page of every single version of the notes and came up with many major improvements. I was also helped by many others who assisted me in developing my courses and writing the notes. I have to mention especially the following: Dave Musser, Jim Dehnert, John Wilkinson, John Banning, Greg Gilley, Mat Marcus, Russell Williams, Scott Byer, Seetharaman Narayanan, Vineet Batra, Martin Newell, Jon Brandt, Lubomir Bourdev, Scott Cohen. (Names are listed in a roughly chronological order of appearance.) It is to them and to my many other students who had to suffer for years through my attempts to understand how to program that I dedicate my book. 2 Alexander Stepanov Notes on Programming 12/24/2018 Lecture 1. Introduction I have been programming for over 30 years. I wrote my first program in 1969 and became a full time programmer in 1972. My first major project was writing a debugger. I spent two whole months writing it. It almost worked. Sadly, it had some fundamental design flaws. I had to throw away all the code and write it again from scratch. Then I had to put hundreds of patches onto the code, but eventually I made it work. For several more years I stuck to this process: writing a huge blob of code and then putting lots of patches to make it work. My management1 was very happy with me. In 3 years I had 4 promotions and at the age of 25 obtained a title of a Senior Researcher – much earlier than all of my college friends. Life seemed so good. By the end of 1975 my youthful happiness was permanently lost. The belief that I was a great programmer was shattered. (For better or for worse, I never regained the belief. Since that time I have been a perplexed programmer searching for a guide. This book is an attempt to share some of the things I learned during my quest.) The first idea was a result of reading the works of the Structured Programming School: Dijkstra, Wirth, Hoare, Dahl. By 1975 I became a fanatical disciple. I read every book and paper authored by the giants. I was, however, saddened by the fact that I could not follow their advice. I had to write my code in assembly language and had to use goto statement. I was so ashamed. And then in the beginning of 1976 I had my first revelation: the ideas of the Structured Programming had nothing to do with the language. One could write beautiful code even in assembly. And if I could, I must. (After all I reached the top of the technical ladder and had to either aspire to something unattainable or go into management.) I decided that I will use my new insight while doing my next project: implementing an assembler. Specifically I decided to use the following principles: 1. the code should be partitioned into functions; 2. every function should be most 20 lines of code; 3. functions should not depend on the global state but only on the arguments; 4. every function is either general or application specific, where general function is useful to other applications; 5. every function that could be made general – should be made general; 6. the interface to every function should be documented; 7. the global state should be documented by describing both semantics of individual variables and the global invariants. The result of my experiment was quite astonishing. The code did not contain serious bugs. There were typos: I had to change AND to OR, etc. But I did not need patches. And over 95% of the code was in general functions! I felt quite proud. There remained a problem that I could not yet precisely figure out what it meant that a function was 1 Natalya Davydovskaya, Ilya Neistadt and Aleksandr
Load more

Recommended publications
  • Thriving in a Crowded and Changing World: C++ 2006–2020
    Thriving in a Crowded and Changing World: C++ 2006–2020 BJARNE STROUSTRUP, Morgan Stanley and Columbia University, USA Shepherd: Yannis Smaragdakis, University of Athens, Greece By 2006, C++ had been in widespread industrial use for 20 years. It contained parts that had survived unchanged since introduced into C in the early 1970s as well as features that were novel in the early 2000s. From 2006 to 2020, the C++ developer community grew from about 3 million to about 4.5 million. It was a period where new programming models emerged, hardware architectures evolved, new application domains gained massive importance, and quite a few well-financed and professionally marketed languages fought for dominance. How did C++ ś an older language without serious commercial backing ś manage to thrive in the face of all that? This paper focuses on the major changes to the ISO C++ standard for the 2011, 2014, 2017, and 2020 revisions. The standard library is about 3/4 of the C++20 standard, but this paper’s primary focus is on language features and the programming techniques they support. The paper contains long lists of features documenting the growth of C++. Significant technical points are discussed and illustrated with short code fragments. In addition, it presents some failed proposals and the discussions that led to their failure. It offers a perspective on the bewildering flow of facts and features across the years. The emphasis is on the ideas, people, and processes that shaped the language. Themes include efforts to preserve the essence of C++ through evolutionary changes, to simplify itsuse,to improve support for generic programming, to better support compile-time programming, to extend support for concurrency and parallel programming, and to maintain stable support for decades’ old code.
    [Show full text]
  • The Art of Unix Programming Next the Art of Unix Programming
    The Art of Unix Programming Next The Art of Unix Programming Eric Steven Raymond Thyrsus Enterprises <[email protected]> Copyright © 2003 Eric S. Raymond Revision History Revision 0.0 1999 esr Public HTML draft, first four chapters only. Revision 0.1 16 November 2002 esr First DocBook draft, fifteen chapters. Released to Mark Taub at AW. Revision 0.2 2 January 2003 esr First manuscript walkthrough at Chapter 7. Released to Dmitry Kirsanov at AW production. Revision 0.3 22 January 2003 esr First eighteen-chapter draft. Manuscript walkthrough at Chapter 12. Limited release for early reviewers. Revision 0.4 5 February 2003 esr Release for public review. Revision 0.41 11 February 2003 esr Corrections and additions to Mac OS case study. A bit more about binary files as caches. Added cite of Butler Lampson. Additions to history chapter. Note in futures chapter about C and exceptions. Many typo fixes. Revision 0.42 12 February 2003 esr Add fcntl/ioctl to things Unix got wrong. Dedication To Ken Thompson and Dennis Ritchie, because you inspired me. Table of Contents Requests for reviewers and copy-editors Preface Who Should Read This Book How To Use This Book Related References Conventions Used In This Book Our Case Studies Author's Acknowledgements I. Context 1. Philosophy Culture? What culture? The durability of Unix The case against learning Unix culture What Unix gets wrong What Unix gets right Open-source software Cross-platform portability and open standards The Internet The open-source community Flexibility in depth Unix is fun to hack The lessons of Unix can be applied elsewhere Basics of the Unix philosophy Rule of Modularity: Write simple parts connected by clean interfaces.
    [Show full text]
  • Lecture #2 "Computer Systems Big Picture"
    18-600 Foundations of Computer Systems Lecture 2: “Computer Systems: The Big Picture” John P. Shen & Gregory Kesden 18-600 August 30, 2017 CS: AAP CS: APP ➢ Recommended Reference: ❖ Chapters 1 and 2 of Shen and Lipasti (SnL). ➢ Other Relevant References: ❖ “A Detailed Analysis of Contemporary ARM and x86 Architectures” by Emily Blem, Jaikrishnan Menon, and Karthikeyan Sankaralingam . (2013) ❖ “Amdahl’s and Gustafson’s Laws Revisited” by Andrzej Karbowski. (2008) 8/30/2017 (©J.P. Shen) 18-600 Lecture #2 1 18-600 Foundations of Computer Systems Lecture 2: “Computer Systems: The Big Picture” 1. Instruction Set Architecture (ISA) a. Hardware / Software Interface (HSI) b. Dynamic / Static Interface (DSI) c. Instruction Set Architecture Design & Examples 2. Historical Perspective on Computing a. Major Epochs of Modern Computers b. Computer Performance Iron Law (#1) 3. “Economics” of Computer Systems a. Amdahl’s Law and Gustafson’s Law b. Moore’s Law and Bell’s Law 8/30/2017 (©J.P. Shen) 18-600 Lecture #2 2 Anatomy of Engineering Design SPECIFICATION: Behavioral description of “What does it do?” Synthesis: Search for possible solutions; pick best one. Creative process IMPLEMENTATION: Structural description of “How is it constructed?” Analysis: Validate if the design meets the specification. “Does it do the right thing?” + “How well does it perform?” 8/30/2017 (©J.P. Shen) 18-600 Lecture #2 3 [Gerrit Blaauw & Fred Brooks, 1981] Instruction Set Processor Design ARCHITECTURE: (ISA) programmer/compiler view = SPECIFICATION • Functional programming model to application/system programmers • Opcodes, addressing modes, architected registers, IEEE floating point IMPLEMENTATION: (μarchitecture) processor designer view • Logical structure or organization that performs the ISA specification • Pipelining, functional units, caches, physical registers, buses, branch predictors REALIZATION: (Chip) chip/system designer view • Physical structure that embodies the implementation • Gates, cells, transistors, wires, dies, packaging 8/30/2017 (©J.P.
    [Show full text]
  • A History of C++: 1979− 1991
    A History of C++: 1979−1991 Bjarne Stroustrup AT&T Bell Laboratories Murray Hill, New Jersey 07974 ABSTRACT This paper outlines the history of the C++ programming language. The emphasis is on the ideas, constraints, and people that shaped the language, rather than the minutiae of language features. Key design decisions relating to language features are discussed, but the focus is on the overall design goals and practical constraints. The evolution of C++ is traced from C with Classes to the current ANSI and ISO standards work and the explosion of use, interest, commercial activity, compilers, tools, environments, and libraries. 1 Introduction C++ was designed to provide Simula’s facilities for program organization together with C’s effi- ciency and flexibility for systems programming. It was intended to deliver that to real projects within half a year of the idea. It succeeded. At the time, I realized neither the modesty nor the preposterousness of that goal. The goal was modest in that it did not involve innovation, and preposterous in both its time scale and its Draco- nian demands on efficiency and flexibility. While a modest amount of innovation did emerge over the years, efficiency and flexibility have been maintained without compromise. While the goals for C++ have been refined, elaborated, and made more explicit over the years, C++ as used today directly reflects its original aims. This paper is organized in roughly chronological order: §2 C with Classes: 1979– 1983. This section describes the fundamental design decisions for C++ as they were made for C++’s immediate predecessor. §3 From C with Classes to C++: 1982– 1985.
    [Show full text]
  • Regarding the Current "Software Crisis" at the Time
    1 www.onlineeducation.bharatsevaksamaj.net www.bssskillmission.in INTRODUCTION TO DATA STRUCTURES Topic Objective: At the end of this topic the student will be able to understand: History of software engineering Software engineering principles Education of software engineering C++ structures and classes Declaration and usage Properties of C++ classes Definition/Overview: Overview: Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches. That is the application of engineering to software. The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thoughtWWW.BSSVE.IN regarding the current "software crisis" at the time. Since then, it has continued as a profession and field of study dedicated to creating software that is of higher quality, cheaper, maintainable, and quicker to build. Since the field is still relatively young compared to its sister fields of engineering, there is still much work and debate around what software engineering actually is, and if it deserves the title engineering. The C++ programming language allows programmers to define program-specific datatypes through the use of structures and classes. Instances of these datatypes are known as objects and can contain member variables, constants, member functions, and overloaded operators defined by www.bsscommunitycollege.in www.bssnewgeneration.in www.bsslifeskillscollege.in 2 www.onlineeducation.bharatsevaksamaj.net www.bssskillmission.in the programmer. Syntactically, structures and classes are extensions of the C struct datatype, which cannot contain functions or overloaded operators. Key Points: 1. History While the term software engineering was coined at a conference in 1968, the problems that it tried to address started much earlier.
    [Show full text]
  • Generic Programming Sean Parent | Principal Scientist “You Cannot Fully Grasp Mathematics Until You Understand Its Historical Context.” – Alex Stepanov
    Generic Programming Sean Parent | Principal Scientist “You cannot fully grasp mathematics until you understand its historical context.” – Alex Stepanov © 2018 Adobe. All Rights Reserved. 2 1988 © 2018 Adobe. All Rights Reserved. 3 © 2018 Adobe. All Rights Reserved. 4 © 2018 Adobe. All Rights Reserved. 4 © 2018 Adobe. All Rights Reserved. 4 “By generic programming we mean the definition of algorithms and data structures at an abstract or generic level, thereby accomplishing many related programming tasks simultaneously. The central notion is that of generic algorithms, which are parameterized procedural schemata that are completely independent of the underlying data representation and are derived from concrete, efficient algorithms.” © 2018 Adobe. All Rights Reserved. 5 “By generic programming we mean the definition of algorithms and data structures at an abstract or generic level, thereby accomplishing many related programming tasks simultaneously. The central notion is that of generic algorithms, which are parameterized procedural schemata that are completely independent of the underlying data representation and are derived from concrete, efficient algorithms.” © 2018 Adobe. All Rights Reserved. 6 “By generic programming we mean the definition of algorithms and data structures at an abstract or generic level, thereby accomplishing many related programming tasks simultaneously. The central notion is that of generic algorithms, which are parameterized procedural schemata that are completely independent of the underlying data representation and are derived from concrete, efficient algorithms.” © 2018 Adobe. All Rights Reserved. 7 “By generic programming we mean the definition of algorithms and data structures at an abstract or generic level, thereby accomplishing many related programming tasks simultaneously. The central notion is that of generic algorithms, which are parameterized procedural schemata that are completely independent of the underlying data representation and are derived from concrete, efficient algorithms.” © 2018 Adobe.
    [Show full text]
  • Modern Computer Architectures Lecture-1: Introduction
    Modern Computer Architectures Lecture-1: Introduction Sandeep Kumar Panda Asso.Prof. IT Department CEB,BBSR 1 Introduction – Computer performance has been increasing phenomenally over the last five decades. – Brought out by Moore’s Law: ● Transistors per square inch roughly double every eighteen months. – Moore’s law is not exactly a law: ● But, has held good for nearly 50 years. 2 Introduction Cont… ● If commercial aircrafts had similar performance increase over the last 50 years, we should have: – Commercial planes flying at 1000 times the supersonic speed. – Aircrafts of the size of a chair. – Costing couple of thousand rupees only. 3 Moore’s Law Gordon Moore (co-founder of Intel) predicted in 1965: “Transistor density of minimum cost semiconductor chips would Moore’s Law: it’s worked for double roughly every 18 months.” a long time. Transistor density is correlated to processing speed. 4 Trends Related to Moore’s Law Cont… • Processor performance: • Twice as fast after every 2 years (roughly). • Memory capacity: • Twice as much after every 18 months (roughly). 5 Interpreting Moore’s Law ● Moore's law is not about just the density of transistors on a chip that can be achieved: – But about the density of transistors at which the cost per transistor is the lowest. ● As more transistors are made on a chip: – The cost to make each transistor reduces. – But the chance that the chip will not work due to a defect rises. ● Moore observed in 1965 there is a transistor density or complexity: – At which "a minimum cost" is achieved. 6 Integrated Circuits Costs IC cost = Die cost + Testing cost + Packaging cost Final test yield Final test yield: Fraction of packaged dies which pass the final testing state.
    [Show full text]
  • Alexander Stepanov Notes on Programming 10/3/2006 Preface
    Alexander Stepanov Notes on Programming 10/3/2006 Preface.............................................................................................................................. 2 Lecture 1. Introduction .............................................................................................. 3 Lecture 2. Designing fvector_int ....................................................................... 8 Lecture 3. Continuing with fvector_int ......................................................... 24 Lecture 4. Implementing swap.............................................................................. 36 Lecture 5. Types and type functions .................................................................. 43 Lecture 6. Regular types and equality............................................................... 51 Lecture 7. Ordering and related algorithms .................................................... 56 Lecture 8. Order selection of up to 5 objects ................................................. 64 Lecture 9. Function objects.................................................................................... 69 Lecture 10. Generic algorithms ............................................................................ 78 10.1. Absolute value ............................................................................................. 78 10.2. Greatest common divisor........................................................................ 83 10.2.1. Euclid’s algorithm..............................................................................
    [Show full text]
  • Evolving a Language in and for the Real World: C++ 1991-2006
    Evolving a language in and for the real world: C++ 1991-2006 Bjarne Stroustrup Texas A&M University www.research.att.com/~bs Abstract Obviously, the C++ community spent the most time and This paper outlines the history of the C++ programming lan- money on the first of those items. The ISO C++ standards guage from the early days of its ISO standardization (1991), committee tends to focus on the second with some concern through the 1998 ISO standard, to the later stages of the for the third. My main effort was on the third and the fourth. C++0x revision of that standard (2006). The emphasis is on The ISO committee is the focus for people who aim to the ideals, constraints, programming techniques, and people improve the C++ language and standard library. Through that shaped the language, rather than the minutiae of lan- such change they (we) hope to improve the state of the guage features. Among the major themes are the emergence art in real-world C++ programming. The work of the C++ of generic programming and the STL (the C++ standard li- standards committee is the primary focus of the evolution of brary’s algorithms and containers). Specific topics include C++ and of this paper. separate compilation of templates, exception handling, and Thinking of C++ as a platform for applications, many support for embedded systems programming. During most have wondered why — after its initial success — C++ didn’t of the period covered here, C++ was a mature language with shed its C heritage to “move up the food chain” and be- millions of users.
    [Show full text]
  • The Genesis of the Mainframe Bob O. Evans
    The Genesis of the Mainframe Bob O. Evans 1 Introduction by Wilhelm G. Spruth In 1927 the German author Stefan Zweig published a short book labeled “Sternstunden der Menschheit” (world hours of mankind). In it he descripes 14 historical events that changed history forever. I have always believed the appearance of System /360 in 1964 has been such an event, changing the direction of the computer industry in more ways than anything else in the last 50 years. The design of the S/360 architecture is rightfully credited to Gene Amdahl, Gerry Blaauw and Fred Brooks. Bob O. Evans has been the IBM executive who made it happen. It is impossible to have met Bob O. Evans and not been impressed. He was forceful, decisive, intelligent, an excellent engineer with a broad vision, an uncanny capability to understand the most complex issues, and an outstanding leader for the people working for him. He also had an overpowering personality. I will be forever grateful for his guidance. In 2002 I learned Bob O. Evans had written his memoirs, had considered to publish them as a book, and had been adviced by his friends not to do so, because the text contained too much sensitive material. I contacted Evans and asked him if I could read the manuscript. He gracefully consented and e-mailed me a copy. Bob O. Evans died in 2004. I believe Bob O. Evans personal account on such a monumental event as the S/360 announcement should be made available. Thus in 2007 I asked his son Douglas B.
    [Show full text]
  • The History of the Enterprise Cloud As Seen by an "Old Mainframer”
    The History of the Enterprise Cloud as Seen by an "Old Mainframer” SM Navigating Information Technology Horizons Published Since 2001 Report #TCG2014009 April 11, 2014 The History of the Enterprise Cloud as Seen by an “Old Mainframer” Analyst: Stephen D. Bartlett Introduction An interesting fact (to me anyway) is that the IBM System/360 (S/360) is just one month older than the Ford Mustang; the S/360 family was announced on April 7, 1964, and the Mustang in May, both in New York City, by the way. In many ways, the product life of this much-coveted vehicle reminds me of and in many ways parallels the S/360 and the 50-year legacy that it spawned. Both demonstrate longevi- ty, certainly, but these remarkable products always have been changing and improving, and have survived many crises, economic downturns, governmental intrusions, technology revolutions, and multiple threats from many competitive venues. Each has endured because of a consistent corporate vision, the dedica- tion of many talented scientists and engineers, and most of all because of the continued enthusiasm, trust, and confidence of its many customers. Even after fifty years, one can never mistake a Mustang for any- thing but a Mustang. And so it also is with the System/360 and its many successor generations of IBM mainframes. Compared to the mean age of the current flock of IT professionals, fifty years is beyond memory; it may even predate the birth of their parents. My career reference point was set by the announcement by IBM of the System/360, marking its fiftieth anniversary this week.
    [Show full text]
  • Short History of STL
    Short History of STL Alexander Stepanov (contributed to Evolving a language in and for the real world: C++ 1991-2007 by Bjarne Stroustrup) In October of 1976 I observed that a certain algorithm – parallel reduction – was associated with monoids: collections of elements with an associative operation. That observation led me to believe that it is possible to associate every useful algorithm with a mathematical theory and that such association allows for both widest possible use and meaningful taxonomy. As mathematicians learned to lift theorems into their most general settings, so I wanted to lift algorithms and data structures. One seldom needs to know the exact type of data on which an algorithm works since most algorithms work on many similar types. In order to write an algorithm one needs only to know the properties of operations on data. I call a collection of types with similar properties on which an algorithm makes sense the underlying concept of the algorithm. Also, in order to pick an efficient algorithm one needs to know the complexity of these operations. In other words, complexity is an essential part of the interface to a concept. In the late 70’s I became aware of John Backus’s work on FP1. While his idea of programming with functional forms struck me as essential, I realized that his attempt to permanently fix the number of functional forms was fundamentally wrong. The number of functional forms – or as I call them now – generic algorithms is always growing as we discover new algorithms. In 1980 together with Dave Musser and Deepak Kapur I started working on a language Tecton to describe algorithms defined on algebraic theories.
    [Show full text]