First meeting of the Interval Subroutine Library group
3rd to 7th October 2005

Links

About the ISL project

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 UK's Engineering and Physical Sciences Research Council to plan and initiate this work. This meeting is the first stage. You can read our Position Paper on the aims of the project.

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 ...

Mission: Provide a full-featured, production quality library of validating routines for use by the wide community of applications developers.

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.

I 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.

Both the Numerical Algorithms Group Ltd (NAG) and Sun Microsystems have expressed interest in the project and have written letters of support, which we gratefully acknowledge.

The ISL Team

• Baker Kearfott, University of Louisiana at Lafayette (Project Leader)
• George Corliss, Marquette University (Schedule Organizer for this meeting)
• John Pryce, RMCS, Cranfield University (Local Organizer for this meeting)
• Ned Nedialkov, McMaster University
• Spencer Smith, McMaster University

Work on Interval Standards

An effort is under way to agree a specification for Interval Arithmetic to be included in the C++ Standard Library. Many people are involved in this and we acknowledge the work of Hervé Brönnimann, Guillaume Melquiond and Sylvain Pion.

Drawing on their drafts, ISL have produced a draft standard document for consideration by the Standards Committee. The theoretical model for this standard is based on Pryce's version of Walster and Hansen's containment set (cset) theory. For a description, see the paper by Corliss and Pryce (Jan 2006).

Meeting venue

Programme details

Our daily schedule is somewhat in the flavor of the Scrum software development method:

Issues to be considered include:

1. Mission -- What is our goal?
   1. Problem?
   2. Target market?
   3. Models?
   4. Scope?
   5. Name?
2. Product -- What will we deliver?
   1. Platforms?
   2. Language?
      C++, Matlab, Fortran, Java, C\#, ...
   3. API - External architecture? Some chapters:
      1. Basic Interval Arithmetic Subroutines
      2. Automatic differentiation
      3. Taylor model arithmetic
      4. Constraint propagation
      5. Linear systems
      6. Nonlinear systems
      7. Optimization
      8. Quadrature
      9. Statistics
      10. Ordinary differential equations
      11. Partial differential equations
   4. License?
3. Organization and process - How will we do that?
   1. Who?
   2. Organization?
   3. Development tools/host?
   4. Internal architecture?
   5. Quality assurance?
   6. Technology transfer -- publication?
   7. Funding?
   8. Marketing and recruiting
4. How can other people help?

There are several inventories I think we need to gather before we go too far. None of these inventories needs to be comprehensive, but I'd like to get a good start on each of them by January.

1. Inventory of target users. As I see it, our target customers are people like Rafi Muhana and Mark Stadtherr who develop interval tools in applications areas. As I see it, if we can make life easier for them and others like them, we will succeed. The inventory includes developers of approximate applications who, under the right conditions, might cross over.
2. Inventory of needs of target users. What could we do that would make Rafi, Mark, and their kind happy? If we build without talking to them, I doubt we get more than 2/3 right. THAT is how we'll know how much I/O we should do, for example.
3. Inventory of vaguely similar software infrastructure efforts to which we can look for management and organizational advice (positive or negative). LAPACK, Open MP, other Open Source, PetSC, ...
4. Inventory of approximate mathematical subroutines to which we can look for advice (positive or negative) on contents, organization, API, support, etc.
5. Inventory of interval packages. Some may candidates for our BIAS layer. Others may yield advice. Some may yield code.
6. Inventory of interval problem-solving routines. These may be candidates for adoption.

   Probably more.

Name? Let's ask people. Thanks to Ned for pointing our Google searches. We should look at some of the reverse search tools that show frequency counts of terms people actually search for. Our opinion does not matter. Opinions of our customers matter.

External applications speakers

The speakers so far are as follows. This is probably the final line-up.

Contact information

(In the UK, replace the +44 by a zero.)

Accommodation

ISL Group members only