Section: Scientific Foundations
Validation and Automation
Validating a code, or generating a validated code, means being able to prove that the specifications are met. To increase the level of reliability, the proof should be checkable by a formal proof checker.
Specifications of qualitative aspects of floatingpoint codes. A first issue is to get a better formalism and specifications for floatingpoint computations, especially concerning the following qualitative aspects:

specification: typically, this will mean a proven error bound between the value computed by the program and a mathematical value specified by the user in some highlevel format;

tight error bound computation ;

floatingpoint issues: regarding the use of floatingpoint arithmetic, a frequent concern is the portability of code, and thus the reproducibility of computations; problems can be due to successive roundings (with different intermediate precisions) or the occurrence of underflows or overflows;

precision: the choice of the method (compensated algorithm versus doubledouble versus quadruple precision for instance) that will yield the required accuracy at given or limited cost must be studied;

input domains and output ranges: the determination of input domain or output range also constitutes a specification/guarantee of a computation;

other arithmetics, dedicated techniques and algorithms for increased precision: for studying the quality of the results, most of conception phases will require multipleprecision or exact solutions to various algebraic problems.
Certification of numerical codes using formal proof. Certifying a numerical code is errorprone. The use of a proof assistant will ensure the code correctly follows its specification. This certification work, however, is usually a long and tedious work, even for experts. Moreover, it is not adapted to an incremental development, as a small change to the algorithm may invalidate the whole formal proof. A promising approach is the use of automatic tools to generate the formal proofs of numerical codes with little help from the user.
Instead of writing code in some programming language and trying to prove it, we can design our own language, wellsuited to proofs (e.g., close to a mathematical point of view, and allowing metadata related to the underlying arithmetics such as error bounds, ranges, and so on), and write tools to generate code. Targets can be a programming language without extensions, a programming language with some given library (e.g., MPFR if one needs a wellspecified multipleprecision arithmetic), or a language internal to some compiler: the proof may be useful to give the compiler some knowledge, thus helping it to do particular optimizations. Of course, the same proof can hold for several targets.
We worked in particular also on the way of giving a formal proof for our correctly rounded elementary function library. We have always been concerned by a precise proof of our implementations that covers also details of the numerical techniques used. Such proof concern is mostly absent in IBM's and Sun's libraries. In fact, many misroundings were found in their implementations. They seem to be mainly due to coding mistakes that could have been avoided with a formal proof in mind. In CRlibm we have replaced more and more handwritten paper proofs by Gappa (http://lipforge.enslyon.fr/www/gappa/ ) verified proof scripts that are partially generated automatically by other scripts. Human error is better prevented.
Integrated and interoperable automatic tools. Various automatic components have been independently introduced above, see § 3.2 and § 3.3 . One of our main objectives is to provide an entire automatic approach taking in input an expression to evaluate (with possible annotations), and returning an executable validated code. The complete automation with optimal or at least good resulting performance seems to be far beyond the current knowledge. However, we see our objective as a major step for prototyping future compilers. We thus aim at developing a piece of software that automates the steps described in the previous pages. The result should be an easytouse integrated environment.