There is much good quality interval software available for basic arithmetic and elementary functions, and for rootfinding and graph plotting, linear algebra, differential equations, global optimization, as well as more specialized applications. But for applications programmers, the software is unappealing: much of it is written in not widely-used languages or is not easily portable for other reasons; agreement on names and meaning of basic interval operations is not universal; installation is very system-dependent, and it can be hard to verify that the infrastructure (e.g. control of rounding modes) is correctly set up; there is no agreement on how to handle exceptional cases such as division by zero, infinite or empty intervals, or square root of intervals containing negative values.
The situation is similar to that of "ordinary" numerical software
some 30 years ago when projects like NAG and IMSL began to remedy it. The ISL
project aims, over a number of years and hopefully with the help of many
collaborators, to do the same for interval software. We have just been given a
small grant by the
The aim is to produce, in stages, a library of interval code that is easy to install and use, efficient within the limits of current technology, thoroughly tested, and covers the basic needs of applications. Because of current trends, the initial implementation is likely to be in C++.
Basic algorithmic research is not our priority. We aim to consolidate existing software from our contributors making the fewest possible changes to the code, while producing a consistent look and feel to the application programming interface and the documentation. The documentation will aim to support all aspects of use of the library: installation and the test suites used to validate it; the foundations of the interval arithmetic model used; techniques, tips and insights to help develop good interval programming practice; description of the individual library chapters and components.
"Basic algorithmic research is not our priority," is accurate, but open to mis-interpretation. Consider ...
Success might be measured by four mutually conflicting criteria with relative weights roughly (fuzzy?):
(30%) Quality: Requirements of customers include "Thou shalt not lie," easy of use at many levels, API that fits needs, etc.
(30%) Timeliness: The sooner the better
(30%) Coverage: The more the better
(10%) Performance: Tightness and speed
We can achieve the best trade-offs by viewing this analogously to traditional librarians. We should not abuse the analogy, but librarians have traditionally gathered the work of others into collections, catalogued it, improved organization and access, and helped people find and use the contents of their collections. We expect to write some bridge classes and make minor modifications to existing codes, but the initial focuses on gathering and organizing to have as wide coverage as quickly as we can.
We think of
Interval arithmetic packages: FILIB, INTLAB, INTLIB, C-XSC, ...
Utility routines: BLAS, Taylor models, constraint propagation, AD, etc.
Problem-solving routines: Ax = b, GlobSol, VNODE, etc.
Applications: Stadtherr, Muhanna, etc.
The primary concern of ISL are Problem-solving routines, but we must have a base of Interval arithmetic packages and Utility routines on which to rest. Utility routines are heavily used by genuine problem-solving routines. They may also be used by applications. Utility routines have been MANY times re-invented by each author of Problem-solving routines. Our biggest service to authors of Problem-solving routines is a well-defined set of utility APIs so authors of Problem-solving routines are free to concentrate on solving problems.
Applications are our customers. We may offer a list of known applications, but we do not include applications in ISL. The requirements gathering for customers' needs can proceed in parallel with the gathering and cataloguing of Interval arithmetic packages and Problem-solving routines:
The borders between these three classes is sometimes quite fuzzy.