Loading in 5 sec....

Tacit Assumptions in the Field of Mathematical SoftwarePowerPoint Presentation

Tacit Assumptions in the Field of Mathematical Software

Download Presentation

Tacit Assumptions in the Field of Mathematical Software

Loading in 2 Seconds...

- 62 Views
- Uploaded on
- Presentation posted in: General

Tacit Assumptions in the Field of Mathematical Software

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Tacit Assumptions in the Field of Mathematical Software

Albert M. Erisman

Seattle Pacific University

Dedicated to John K. Reid

at the celebration of his 70th birthday

- Two stories
- Six Assumptions and their implications
- Some questions for those working in the field of mathematical software

July

1972

- I need to build a mathematical model
- The algorithm at the heart of the model is
- The most complex part of the simulation
- The part that drives performance and reliability of the entire simulation

- By using a standard piece of mathematical software rather than writing this part of the code myself, I can
- Save time and money
- Improve the reliability of the simulation
- Draw on expertise I don’t have

- Early weakness in that model
- Mathematical software was primarily “shareware”
- Often it was questionable in its performance and reliability

- These factors led to the field of mathematical software

A tacit assumption or implicit assumption is an assumption that includes the underlying agreements or statements made in the development of a logical argument, course of action, decision, or judgment that are not explicitly voiced nor necessarily understood by the decision maker or judge. [Wikipedia]

Six tacit assumptions that drove the field from the 1960s

- Scientists and engineers develop their own mathematical simulation codes.

- For most standard computations (structures, electromagnetics, electronics, chemical process simulation, linear programming, …) most scientists and engineers use standard software developed in their fields enabling
- commonality and comparison of results
- cost and time savings

- The mathematical software in that simulation is largely invisible to the user

- Who is the customer for the mathematical software?

Mathematical software was exchanged for free.

- There were no were no intellectual property issues,
- This software could readily be used as building blocks for larger simulations.

- IBM started the trend limiting distribution of math software in 1969
- The change created a business opportunity for mathematical software libraries (NAG, IMSL)

- A great deal of this software both costs money and has IP restrictions on its use.
- IP restrictions often inhibit the use of the mathematical software in the resulting simulation code.

- If reuse (and remix) is the goal, are the standard practices for the distribution of software standing in the way of its reuse?
- How do these realities get taken into account in the distribution and restrictions on mathematical software?
- If the software is exchanged for free without restriction, who pays the salaries of the developers?

- Mathematical software was designed for scalar computers.
- Reducing the computation time for the mathematical software directly translated into a reduction in computational time for the simulation.

Algorithm performance

Algorithm performance

- Mathematical simulations on parallel computers raise new questions.
- Should the algorithms be optimized for the parallel computer, or should the simulation be optimized?
- Are these the same?

- Should the algorithm developer try to achieve maximal parallelization for the algorithm, or
- Should the developer create software that will support the best parallelization of the resulting simulation code?
- What other issues should we be thinking about?

- Mathematical software was primarily used in simulation applications run on mainframe computers (and vector computers).
- The changes in this hardware could be readily applied to the libraries, simplifying the challenge for the user in migrating his or her code from one machine to another.
- The frequency of use of the mathematical software could easily be measured on the mainframes.

- This started to change with the coming of the PC.
- With today’s powerful microchips and larger memories, mathematical simulations are done on all kinds of devices including hand held and onboard.
- The architectures are very diverse leading the challenges in creating standard code with ideal performance across these platforms.

- How might the mathematical software be distributed and managed in such a way that users can tailor it for their own environments?
- Who troubleshoots problems with the software when a user changes the code?

Mathematical software was generally written in Fortran or Algol, since most scientific computation was done in these languages.

- The diversity of platforms may call for many versions (and languages of implementation) of the same algorithm
- No single version, even with machine dependent adaptations, may be suitable.

- Questions of tailoring and troubleshooting persist as the software is adapted to different computing environments and programming languages

- The structure of libraries was driven by a mathematical taxonomy: special functions, solution of linear algebraic equations, curve and surface fitting, ordinary differential equations, etc.
- Completeness of coverage could be measured by the most commonly used entries in this taxonomy without too much knowledge about the details of the various simulations.

- Problem characteristics in a particular simulation may dictate algorithm variations that don’t neatly fit the “general purpose” mathematical taxonomy
- Complex symmetric (not hermitian) matrix solutions
- Sparse matrices with specific patterns
- Fixed step ODE solvers
- Very specialized curve and surface fitting tools

Simulation

Library

- How is an external library adapted to specific applications contexts, where that library may need new functionality driven by specific applications?
- How does a library organize and support important but non-standard algorithms?

- Assumptions 2 (IP issues), 4 (diversity of environments) and 6 (specialized requirements) kept us from adopting a commercial library as our foundation at Boeing. We studied the issue four or five times from 1980 till 2001.

- In spite of the changing assumptions in the field of mathematical software, the need for mathematical software persists and grows
- Once confined to simulations, math software is now at the heart of robotics, elevator operations, flight controls, GPS devices, etc.
- However, the world in which this software is needed is much more complex, with
- Many users migrating to “off the shelf” software
- New applications requiring non-standard algorithms
- Significant reuse questions
- Diverse environments challenging the measure of use, standards of delivery, and the stability of the software

- Mathematical software was started with a collection of tacit assumptions in the 1960s
- These assumptions are no longer valid
- As in the case of land ownership and airplanes, or IP issues and remix capability, this calls for rethinking basic issues
- I offer these questions for your consideration

- I would like to thank Thomas Grandine from Boeing for help in the preparation of these ideas
- Ronald F. Boisvert, “Mathematical Software: Past, Present and Future,” Mathematics and Computers in Simulation, vol. 54, 2000, pp. 227-241
- Unknown remix artist