Formal Verification of Programs Computing the Floating-Point Average

Abstract

The most well-known feature of floating-point arithmetic is the limited precision, which creates round-off errors and inaccuracies. Another important issue is the limited range, which creates underflow and overflow, even if this topic is dismissed most of the time. This article shows a very simple example: the average of two floating-point numbers. As we want to take exceptional behaviors into account, we cannot use the naive formula (x+y)/2. Based on hints given by Sterbenz, we first write an accurate program and formally prove its properties. An interesting fact is that Sterbenz did not give this program, but only specified it. We prove this specification and include a new property: a precise certified error bound. We also present and formally prove a new algorithm that computes the correct rounding of the average of two floating-point numbers. It is more accurate than the previous one and is correct whatever the inputs.

A Formally-Proved Algorithm to Compute the Correct Average of Decimal Floating-Point Numbers

“…Moreover, our algorithm still works for any even radix. The algorithm provided by Boldo [12] for the radix-2 case exploits the fact that there is a division by 2 in the average computation. We think it is possible to provide a similar correct algorithm to compute x+y 10 in radix-10 arithmetic, or more generally x+y β with an even radix β.…”

“…In the case of our decimal average, we could have written a C program, but we could not have formally certified it. There are available tools to formally verify C programs, such as Frama-C and Why3 [20], [21] that were used for the radix-2 average algorithm [12]. However, they do not support decimal arithmetic.…”

“…A corresponding algorithm has been proved by Boldo [12] to guarantee both the accuracy and Sterbenz's requirements. This gives a long program as a full sign study is needed.…”

“…if (C <= abs(x)) return x/2+y/2; else return (x+y)/2; } with a constant C that can be chosen between 2 −967 and 2 970 . This program was formally proved to provide the correct result even in case of underflow and to never create spurious overflow [12].…”