Project 61: Numerical Software in fault-tolerant Environments. 

Argonne 1986:
=============

Document: IFIP/WG 2.5 (Argonne-25) 1325, 8 pages.

As part of the proposal for a new WG 2.5 project, Vouk presented
information on the use of numerical software in (life-)critical
environments. In fault tolerant applications numerical software
provides an additional dimension of complexity through, for example,
accuracy and tolerance problems, and the possibility of multiple
correct solutions/answers. Use of the "off-the-shelf" numerical
software components (e.g. numerical libraries) for implementation of
fault-tolerant software functions may be a problem if the diversity of
the algorithms, and implementations among the available libraries was
limited. A study of numerical software properties which are important
in fault-tolerant software environments, such as correlated faults due
to accuracy, implementation or similarity of commonly employed
algorithms, was proposed. In addition, a set of quantitative and
qualitative measures suitable for description of numerical software
intended for critical applications and environments will be
investigated.

Como 1987:
==========

Vouk informed WG 2.5 that little reportable work was completed in the
past year, but that the topic is still of interest and the project
should be continued. A brief discussion developed regarding some
possible issues (e.g. consistency checking of results). (Ford, Rice,
Feldman, Gentleman)

Stanford 1988:
==============

Document:	IFIP/WG 2.5 (Stanford-21) 1521, 1 page.

M. Vouk briefly reported on his activities related to the project. 
He talked about "back-to-back" testing of functionally equivalent
software and on some problems with voting algorithms when finite
precision arithmetic is used for adjudication of the correctness 
of an answer.

Jerusalem 1990:
===============

Vouk noted that many of the problems that are encountered with
numerical software when software fault-tolerance is considered arise
from numerical precision and error propagation. He suggested that
project [47] addresses great many of these questions and that it would
be more economical to merge [61] into [47]. This was accepted. The
project will be kept open.