Results 1 
3 of
3
Floating point verification in HOL Light: the exponential function
 UNIVERSITY OF CAMBRIDGE COMPUTER LABORATORY
, 1997
"... Since they often embody compact but mathematically sophisticated algorithms, operations for computing the common transcendental functions in floating point arithmetic seem good targets for formal verification using a mechanical theorem prover. We discuss some of the general issues that arise in veri ..."
Abstract

Cited by 36 (7 self)
 Add to MetaCart
Since they often embody compact but mathematically sophisticated algorithms, operations for computing the common transcendental functions in floating point arithmetic seem good targets for formal verification using a mechanical theorem prover. We discuss some of the general issues that arise in verifications of this class, and then present a machinechecked verification of an algorithm for computing the exponential function in IEEE754 standard binary floating point arithmetic. We confirm (indeed strengthen) the main result of a previously published error analysis, though we uncover a minor error in the hand proof and are forced to confront several subtle issues that might easily be overlooked informally. The development described here includes, apart from the proof itself, a formalization of IEEE arithmetic, a mathematical semantics for the programming language in which the algorithm is expressed, and the body of pure mathematics needed. All this is developed logically from first prin...
HOL Light Tutorial (for version 2.20)
, 2007
"... The HOL Light theorem prover can be difficult to get started with. While the manual is fairly detailed and comprehensive, the large amount of background information that has to be absorbed before the user can do anything interesting is intimidating. Here we give an alternative ‘quick start ’ guide, ..."
Abstract

Cited by 9 (0 self)
 Add to MetaCart
(Show Context)
The HOL Light theorem prover can be difficult to get started with. While the manual is fairly detailed and comprehensive, the large amount of background information that has to be absorbed before the user can do anything interesting is intimidating. Here we give an alternative ‘quick start ’ guide, aimed at teaching basic use of the system quickly by means of a graded set of examples. Some readers may find it easier to absorb; those who do not are referred after all to the standard manual. “Shouldn’t we read the instructions?”
Formalizing Dijkstra
"... Abstract. We present a HOL formalization of the foundational parts of Dijkstra's classic monograph "A Discipline of Programming". While embedding programming language semantics in theorem provers is hardly new, this particular undertaking raises several interesting questions, ..."
Abstract
 Add to MetaCart
Abstract. We present a HOL formalization of the foundational parts of Dijkstra's classic monograph &quot;A Discipline of Programming&quot;. While embedding programming language semantics in theorem provers is hardly new, this particular undertaking raises several interesting questions, and perhaps makes an interesting supplement to the monograph. Moreover, the failure of HOL's first order proof tactic to prove one `theorem ' indicates a technical error in the book. 0 A Discipline of Programming Dijkstra's &quot;A Discipline of Programming &quot; [4] is widely, and we think rightly, regarded as a classic. As he describes it, the original intention was to present some algorithms, emphasizing the process of discovery leading to them rather than giving them as cutanddried results. However, Dijkstra also wished to present the programs using more mathematical rigour than is the norm. The book emphasizes a view of a program as an abstract mathematical object, whose runnability on a machine is, so to speak, a fortunate accident: Historically speaking... the fact that programming languages could be used as a vehicle for instructing existing automatic computers... has for a long time been regarded as their most important property.... I view a programming language primarily as a vehicle for the description of (potentially highly sophisticated) abstract mechanisms. [pp. 89] Dijkstra's main technical innovation, covered in depth for the first time in this book, is the use of predicate transformers to give the semantics of programs. Predicate transformer semantics is quite convenient for formal correctness proofs, since it has a direct relationship with the satisfaction of appropriate inputoutput conditions. Moreover, it turned out [1] that one could introduce predicate transformers not implementable as code, and use these as stepping stones in formal program derivations, giving a natural formalization of informal topdown design methods. Dijkstra was one of the earliest and strongest advocates of formal correctness proofs of programs rather than extensive testing. Nowadays this point of view is increasingly having a practical impact, with major hardware companies pursuing formal verification. But for a long time Dijkstra must have felt like a prophet crying in the wilderness.