Diploma Thesis

Exploration of the Suitability of O-O Techniques for the Design and Implementation of a Numeric Math Library using Eiffel Diploma Thesis Peter Häfliger advised by Prof. Dr. Bertrand Meyer and Susanne Cech ETH Zürich March 9, 2003 Abstract This diploma thesis is organized in three parts. The first part defines a problem which Bertrand Meyer calls the ‘Scientific Software Paradox’ and shows its historic evolution. The creation of an object-oriented mathematics library is proposed as a possible path out of the paradox. The second part describes the work done on two sample components of the proposed library. The third part evaluates the work on these components and tries to induce from this experience the perspectives of a full library. Declaration of Authenticity I submit this report as the thesis for my diploma in Computational Science and Engi- neering at the Department of Mathematics at the Swiss Federal Institute of Technology ETHZ. It describes the work I have done between November 1st, 2002, and March 1st, 2003, at the Chair of Software Engineering at the Department of Computer Science at ETHZ. I declare that the work described is my original contribution to the field. Foundations laid by others upon which my work is built have been correctly cited and referenced according to my best knowledge. Zürich, March 9th, 2003 Peter Häfliger Acknowledgements To prevent this list from filling up my whole report, I will restrict it to the three people who have inspired me most in the course of the last four months: First and most of all, I thank Prof. Bertrand Meyer for having offered me the very first diploma project at his newly established Chair of Software Engineering. It has been a great privilege to work in such a close collaboration with one of the pioneers of our field. I thank Susanne Cech for the loyal and generous support she has always given me, starting with a task as boring as the installation of Microsoftr Windows XP on my machine, moving on to careful reviews of all my code and up to the final proof-reading of my report at the unusual working hour of a Sunday morning. Finally, I thank my friend and fellow-student Torsten Hofmann. Besides the work on his own diploma thesis in Fluid Dynamics and the pursuits of diverse interests such as Perl hacking, he has always found the time to make a comment on my various design attempts. Contents Abstract . iii Declaration of Authenticity . iii Acknowledgements . iii I Introduction 1 1 The Problem to be Addressed 3 1.1 The Scientific Software Paradox . 3 1.2 Historical Background and State of the Art . 4 2 The Solution to be Investigated 15 2.1 Evolution of the Basic Idea . 15 2.2 Evolution of the Project . 16 2.3 Tasks to be Accomplished and Questions to be Answered . 17 2.4 Outline of the Thesis . 18 II Sample Components 21 3 Special Functions: The Last Resort of C 23 3.1 C Language Standards . 24 3.2 DOUBLE MATH ............................... 25 3.3 SPECIAL FUNCTIONS ........................... 26 3.4 Conclusion . 38 4 Integration: A Playground for Agents 41 4.1 A first Approach: View Inheritance Type Hierarchy . 43 4.2 Start from Scratch: An Integrator is an Iterator . 46 4.3 The Important Question: Is it General Enough? . 60 v III Evaluation 63 5 Evaluation of the Sample Components 65 5.1 Benefits of a Full O-O Approach to Scientific Computing . 65 5.2 Possible Drawbacks, Challenges and Open Issues . 66 5.3 Performance Analysis . 66 6 Perspectives of a Full O-O Math Library 77 6.1 Feasibility, Advantages, Challenges . 77 6.2 Specification of Basic Platform Requirements . 78 6.3 Estimate and Modularizability of the Work to be Done . 79 6.4 A Possible Work Plan . 79 6.5 Related Fields . 80 Bibliography 81 Part I Introduction 1 Chapter 1 The Problem to be Addressed The first chapter tries to motivate the research done within the scope of this diploma thesis by sketching the problem that has been addressed and by placing it in its historic context. The ground shall be prepared for the solution proposed in the second chapter. 1.1 The Scientific Software Paradox The problem which this diploma thesis addresses is the ‘Scientific Software Paradox’ as described by Bertrand Meyer at the beginning of his preface to Paul Dubois’ book on the EiffelMath library ([OTSC]): “Scientific software is a paradoxical product. The people creating it are, as one may expect, scientists: physicists, mathematicians, chemists, experts in mechanical, electrical, or aeronautical engineering. In most cases, however, the product itself is surprisingly unscientific. Software engineering advances of the past three decades have penetrated this field more slowly than areas such as compilers, systems software, user interfaces, telecommu- nications, or even Management Information Systems. Two reasons can be found to explain the Scientific Software Paradox. The first is the age of the field: being the oldest application of computers — actually, the one that prompted the very idea of a computer – it has had to bear the weight of tradition, like an ancient and prestigious indus- trial metropolis that finds itself bypassed by upstart cities unencumbered by existing infrastructure. In this case, a large part of the infrastructure is Fortran, the language of choice of the scientific software community, once a brilliant invention which today finds it hard to keep up with the progress of modern software ideas. The other reason for the paradox is that many scientific programmers, unlike their colleagues in other application areas, do not have programmer or software engineer on their business cards: their job title reads rocket scientist or the like, and they think of themselves as professionals in fields other than software even if – as is often the case – much or most of their time is spent dealing with computers.” 3 4 CHAPTER 1. THE PROBLEM TO BE ADDRESSED 1.2 Historical Background and State of the Art 1.2.1 Programming Languages and Software Engineering The Search for ever Higher Levels of Abstraction Since the invention of the first programmable computers more than 60 years ago, the de- signers of new Programming Languages and the developers of new Software Engineering Techniques have strived at ever more abstraction. 1 In the late 1940s and the better part of the 1950s, computers were first programmed directly in machine language, later in assembly language. Assembly languages already improved the writability and readability of computer programs for human programmers by replacing the bit series for each machine instruction with a three-letter mnemonic. But the programmer still had to think in individual machine instructions when he was designing his programs. No support for abstraction was offered yet. IBM’s FORmula TRANslating System (FORTRAN), for which the first compiler was released in April 1957, was a quantum leap: FORTRAN I was the first major high-level language which offered some basic high-level constructs we all take for granted today: • user-definable subroutines • conditional branching (IF clause) • loops (DO clause) One year after the release of FORTRAN I, FORTRAN II added support for independent compilation of subroutines. In 1962, FORTRAN IV added type declarations and the capability of passing subprograms as parameters to other subprograms. FORTRAN 77 added a few more features like string handling and an optional ELSE clause to the IF clause. FORTRAN 90 was a radical change to the language: • A large set of functions for array operations was built in. • New control statements like the multiple selection CASE were added. • Modular programming is supported like in Ada or Modula-2. • Arrays can be dynamically allocated and deallocated on command if they have been declared to be ALLOCATABLE. • Procedures can now be called recursively. 1For more background on the History of Programming Languages, see [Sebesta], chapter 2, from which I have learned a lot of what I have tried to summarize in this subsection. 1.2. HISTORICAL BACKGROUND AND STATE OF THE ART 5 Especially the last two changes are dramatic: They depart from the original FORTRAN concept of allowing static data only. In the earlier FORTRANs, no recursive subprograms were allowed and no new variables could be allocated at run time. This made it difficult to implement data structures that grow or change shape dynamically. But since the types and storage for all variables could be determined at compile time, the construction of highly optimizing compilers was possible. Mathematicians were willing to trade design flexibility for better performance, but software engineers soon turned to more expressive languages. With FORTRAN 90, the FORTRAN family tried to re- enter the club of state-of-the-art programming languages 2, but as far as I can judge, the scientific computing community has not followed. Their reason for not making the transition from FORTRAN 77 to FORTRAN 90 is exactly their reason for favouring FORTRAN in the first place: Performance is their top priority, more important than flexibility or modularity. Where I have seen FORTRAN at work, it was usually FOR- TRAN 77. If I write FORTRAN without any further qualification in the following text, I always refer to FORTRAN 77. In the wake of the first FORTRAN versions, many other early high-level languages were developed. This ‘babylonic’ situation made communication between different commu- nities difficult. Furthermore, these languages were usually specific to a single computer architecture. People started realizing the need for a ‘universal’ programming language. FORTRAN was no candidate because at the time it was actually owned by IBM. AL- GOL was a transatlantic joint effort of ACM3 and GAMM4 to design a language subject to the following criteria: • It should be as close as possible to standard mathematical notation, and programs written in it should be readable with little further explanation.

Load more