From ownerreliable_computing Fri Apr 5 06:11:12 1996
Received: by interval.usl.edu id AA09651
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Fri, 5 Apr 1996 12:11:46 0600
Received: from bp.ucs.usl.edu by interval.usl.edu with SMTP id AA09645
(5.65c/IDA1.4.4 for ); Fri, 5 Apr 1996 12:11:42 0600
Received: from rbk5287.usl.edu by bp.ucs.usl.edu with SMTP id AA03563
(5.65c/IDA1.4.4 for ); Fri, 5 Apr 1996 12:11:12 0600
Date: Fri, 5 Apr 1996 12:11:12 0600
MessageId: <199604051811.AA03563 [at] bp [dot] ucs.usl.edu>
XSender: rbk5287 [at] pop [dot] usl.edu
XMailer: Windows Eudora Light Version 1.5.2
MimeVersion: 1.0
ContentType: multipart/mixed; boundary="=====================_828735018==_"
To: reliable_computing [at] interval [dot] usl.edu
From: "R. Baker Kearfott"
Subject: Standardized interval arithmetic in Fortran
XAttachments: C:\FORTRA~1\STANDARD\X3J3.FEB\F96PRO.ASC;
Sender: ownerreliable_computing
Precedence: bulk
=====================_828735018==_
ContentType: text/plain; charset="usascii"
Colleagues:
We have just submitted a proposal to X3J3, the United States committee
charged with developing the Fortran programming language. The proposal
is a preliminary draft meant, in part, to help the committee decide how to
pursue the matter.
Nonetheless, the draft represents significant work and thought of our group.
Various considerations, including precedent, ease of implementation,
ease of use, and consistency, went into the design.
Of particular interest to us may be the proposal for I/O for intervals.
Regardless of the decisions of X3J3, it should be possible for us to
agree on a defacto standard. Much of the proposal (excepting
the I/O, operator precedence, and other items except as indicated below
the proposal) can be implemented presently as a module in Fortran 90.
Also, Fortran 2000 may contain derivedtype I/O in a form that allows
reasonable implementation of the I/O. In any case, it will be useful for
us to think about what we want, to promote portability and reuse of
intervalrelated software in Fortran.
I have attached the draft proposal. I will welcome comments and answer
questions.
Best regards,
Baker
=====================_828735018==_
ContentType: text/plain; charset="usascii"
ContentDisposition: attachment; filename="F96PRO.ASC"
A SPECIFIC PROPOSAL FOR INTERVAL ARITHMETIC IN FORTRAN
March 20, 1996
compiled by
R. Baker Kearfott
as a result of discussions in the group consisting of
Keith Biermann
George Corliss
David Hough
Andrew Pitonyak
Michael Schulte
William Walster
Wolfgang Walter
CONTENTS
________
I. INTRODUCTION
II. GENERAL PRINCIPLES
III. THE INTERVAL DATA TYPE AND INTERVAL INTRINSIC FUNCTIONS
A. The Data Type and Basic Operations
B. New Infix Operators
C. Interval Versions of Relational Operators
D. Special Interval Functions
E. Interval Versions of the Intrinsics
IV. INTERVAL I/O
A. Interval Constants
B. The Interval VF Edit Descriptor
C. The Interval VE Edit Descriptor
D. The Interval SE and SF Edit Descriptors
E. The Interval SG and VG Edit Descriptors
F. Other Interval I/O
G. An Example
V. ADDITIONAL NOTES (not part of proposal proper)
A. On Optimization of Interval Expressions
B. Can Interval Arithmetic be Implemented Effectively in a Module?
=======================================================================
I. INTRODUCTION
This document is to propose standard syntax and requirements for
interval computations in Fortran, and to give occasional guidelines for
implementation. These requirements are based upon precedents, as well
as thorough discussion of various points.
II. GENERAL PRINCIPLES
Containment: Every interval result must CONTAIN the exact mathematical
range of the corresponding point operation or function evaluation.
Note: Containment is crucial for verification and validation
computations to be rigorous, and is easy to achieve using
floating point arithmetic and directed rounding, as defined by
the IEEE 754 standard, or (less accurate) simulations thereof.
Accuracy: There is no accuracy requirement.
Note: The lack of an accuracy requirement facilitates
universal implementation of the standard syntax.
Note: Ideally, results of the elementary operations and
intrinsic functions should have as small a width as is
mathematically possible subject to the condition that the
result contain the exact mathematical range. This is not
difficult for the four basic operations "+", "", "*", and "/",
if IEEE 754 arithmetic is available. For the standard
functions, a more realistic goal is that the lower bound be at
most 1ULP (unit in the last place) less than the ideal lower
bound, and that the upper bound be at most 1ULP more than the
ideal upper bound.
Speed: There is no speed requirement.
Note: It is reasonable to expect machinespecific
implementations to come within a factor of 5, or perhaps within
a factor of 2, of the speed of point arithmetic. This is
particularly true if IEEE 754 is available and if the floating
point standard function library was designed to produce results
with known relative accuracy.
Intrinsic data type: The proposed standard requires an intrinsic
interval data type to implement interval arithmetic in Fortran.
Note: Some, but not all, aspects of the standard can be
implemented in a module. In particular, the interval edit
descriptors for interval I/O (VE, VF, and VG formats, as well
as extensions of the standard formats to interval computations)
cannot be implemented within a module, although subroutine
calls can be used to implement interval I/O. The representation
of interval constants within Fortran executable statements,
e.g. representing the interval [1,2] as (<1,2>) on the right
side of an assignment statement, cannot be done with a module.
Also, type parameters for the interval data type cannot be
implemented with a module. Finally, there is no way to define
the natural precedence of interval operators within a module.
In addition to the containment requirement, the following items
are required:
* an INTERVAL numeric data type, obeying the same syntax as the other
numeric data types,
* several new infix operators and intrinsics,
* INTERVAL versions of all Fortran 90 intrinsics that accept REAL
data,
* natural extensions to Fortran standard I/O to include intervals.
Note: A complex interval data type is neither required nor
prohibited.
Note: Various forms of extended interval arithmetic are neither
prohibited nor required. There are at least three different
extended interval arithmetics (Kahan arithmetic, Kaucher
arithmetic, and Markov arithmetic), all useful but designed for
different purposes.
III. THE INTERVAL DATA TYPE AND INTERVAL INTRINSIC FUNCTIONS
A. The Data Type and Basic Operations
__________________________________
Name and structure: The INTERVAL type is a numeric type. Its values
are closed and bounded real interval which are defined by an ordered
pair of real values. The first real value is the lower bound (or
infimum), the second real value is the upper bound (or supremum). All
real numbers between and including these two bounds (or endpoints) are
said to be elements of the interval.
Arithmetic operations: The four basic operations +, , *, are defined
to contain the ranges of the corresponding operations on real numbers.
Specifically, let X = [xl,xu] an Y = [yl,yu] be intervals, where xl
represents the lower bound of X, xu represents the upper bound of X, yl
represents the lower bound of Y, and yu represents the upper bound of
Y. Then:
X + Y shall contain the exact value [xl + yl, xu + yu],
X  Y shall contain the exact value [xl  yu, xu  yl],
X * Y shall contain the exact value
[min{xl*yl, xl*yu, xu*yl, xu*yu}, max{xl*yl, xl*yu, xu*yl, xu*yu}]
1 / X shall contain the exact value
 [1/xu, 1/xl] xu < 0 or xl > 0

 [inf, inf] otherwise
where "inf" is the abbreviation for the symbols IEEE_NEGATIVE_INF and
IEEE_POSITIVE_INF stipulated below.
X / Y shall contain the exact value
[min{xl/yu, xl/yl, xu/yu, xu/yl}, max{xl/yu, xl/yl, xu/yu, xu/yl}]
if yu < 0 or yl > 0
and shall be equal to [inf, inf] otherwise.
Note: The second case of interval division may be replaced by
sharper definitions on particular processors in a separate
extended interval arithmetic.
Note: Using floating point arithmetic, the operations on the
righthand sides may first be computed, then the lower bound
may be rounded down to a number known to be less than or equal
to the exact mathematical result, and the upper bound may be
rounded up to a number known to be greater than or equal to the
exact mathematical result. If a processor provides directed
roundings upwards (towards plus infinity) and downwards
(towards minus infinity), then the operation and the rounding
can be performed in one step, e.g. if the processor conforms to
the IEEE 754 standard. The excess interval width caused by
this outward rounding is called ROUNDOUT ERROR.
Note: There is an alternate implementation of interval
multiplication that also gives the range of the real operator
"*" over the intervals X and Y. This alternative involves nine
cases determined by the algebraic signs of the endpoints of X
and Y; see page 12 of R. E. Moore, "Methods and Applications of
Interval Computations," SIAM, Philadelphia, 1979. The average
number of multiplications required for this alternative is less
than above, but one or more comparisons are required.
Implemented in software, the relative efficiencies of the
alternative above and the ninecase alternative are
architecturedependent, although the ninecase alternative is
often preferred in lowlevel implementations designed for
efficiency.
Note: The only processor requirement is that the computed
intervals contain the exact mathematical range of the
corresponding point operations. In an ideal implementation (not
required), the result of the operations is the smallestwidth
machine interval that contains the exact mathematical range.
Note: IEEE arithmetic helps with outward roundings. For example
take
[xl,xu] + [yl,yu] = [xl+yl,xu+yu]
in exact interval arithmetic. The IEEE 754 standard defines a
downwardly rounded operation as producing the same result as
would be obtained by computing the exact result, then rounding
it to the nearest floating point number less than or equal to
the exact result, and an upwardly rounded operation as
producing the same result as would be obtained by computing the
exact result, then rounding it to the nearest floating point
number greater than or equal to the exact result. Thus, if the
result xl+yl is rounded down and xu+yu is rounded up
according to the IEEE specifications, an ideal interval
addition results.
Infinities: Two (caseinsensitive) symbols, IEEE_NEGATIVE_INF and
IEEE_POSITIVE_INF, shall also be defined.
Note: IEEE_NEGATIVE_INF and IEEE_POSITIVE_INF correspond to
negative infinity and positive infinity in IEEE arithmetic, but
shall be defined on all processors. The symbol IEEE_NEGATIVE_INF
represents something less than all floating point numbers, and
IEEE_POSITIVE_INF represents something greater than all floating
point numbers. Intervals with one or both endpoints equal to
these symbols shall be allowed, and arithmetic on them is
defined, consistently with IEEE arithmetic.
The empty set: The interval ()
shall represent the empty set.
Note: Intervals in which the upper endpoint is less than the
lower endpoint are nonstandard. However, various useful
nonstandard extensions can be based on such representations.
Mixed mode operations: mixedmode INTERVAL/REAL and mixed mode
INTERVAL/INTEGER operations shall be defined. The result of such a
mixedmode operation shall be the same as if the other data type
(INTEGER or REAL) were first converted to an INTERVAL that contains the
mathematical interpretation of the original data type.
Note: Mixedmode INTERVAL/COMPLEX is not defined.
No implicit conversion from interval: Implicit conversion from interval
to other data types shall not be allowed.
Note: The functions INF and SUP defined below may be used to
convert an INTERVAL to another data type. Similarly, MID may
also be viewed as producing a real approximation to an
interval, while INTERVAL converts from real to interval.
Implicit conversion to interval: Implicit conversion to interval shall
be possible. The result of an implicit conversion to interval shall
contain the mathematical interpretation of the original data type.
Type parameters: The INTERVAL data type shall admit one or more type
parameters. Each type parameter shall be equal to the corresponding REAL
type parameter.
Note: The default INTERVAL type should correspond to a REAL type
with at least 64 bits. ("DOUBLE PRECISION" on many machines). It
is the consensus of experts that 32bit interval arithmetic is
of limited use.
B. New Infix Operators
___________________
The following infix operators shall be a part of standard interval
support.
Syntax function
______ ________
Z = X.IS.Y Z < intersection of X and Y, that is,
[max{xl,yl},min{xu,yu}] if
max{xl,yl} < = min{xu,yu} and
[inf,inf] otherwise.
Z = X.CH.Y Z < [min{xl,yl}, max{xu,yu}]
("interval hull" of X and Y. The mnemonic is
"convex hull")
X.SB.Y .TRUE. if X is a subset of Y
( i.e. if xl >= yl .AND. xu <= yu )
X.PSB.y .TRUE. if X is a proper subset of Y
( i.e. if X.SB.Y .AND. (xl > yl .OR. xu < yu )
X.SP.Y .TRUE. if and only if Y.SB.X is true
( i.e. if xl <= yl .AND. xu >= yu )
X.PSP.Y .TRUE. if and only if Y.PSB.X is true
( i.e. if Y.SB.X .AND. (yl > xl .OR. yu < xu )
X.DJ.Y .TRUE. if X and Y are disjoint sets
( i.e. if xl > yu or xu < yl )
R.IN.X .TRUE. if the REAL value R is contained in the
interval X (i.e. if xl <= R <= xu)
Note: Intervals are viewed as closed intervals, so, if R.IN.X,
then R may be equal to one of the endpoints of X.
C. Interval Versions of Relational Operators
_________________________________________
The following relational operators shall be extended to interval
operations, in the "certainly true" sense. That is, the result is .TRUE.
if and only if it is true for each pair of real values taken from the
corresponding interval values.
Syntax function
______ ________
X.LT.Y .TRUE. if xu < yl
X.GT.Y .TRUE. if xl > yu
X.LE.Y .TRUE. if xu <= yl
X.GE.Y .TRUE. if xl >= yu
As with noninterval data types in the Fortran standard, the newer
symbols "<", ">", "<=",and ">=" shall be interchangeable with ".LT.",
".GT.", ".LE.", and ".GE.", respectively.
Another set of relational operators, the POSSIBLY TRUE relationals,
shall be defined as follows.
Syntax function
______ ________
X.PLT.Y .TRUE. if xl < yu (i.e. if .NOT.(X.GE.Y) )
X.PGT.Y .TRUE. if xu > yl (i.e. if .NOT.(X.LE.Y) )
X.PLE.Y .TRUE. if xl <= yu (i.e. if .NOT.(X.GT.Y) )
X.PGE.Y .TRUE. if xu >= yl (i.e. if .NOT.(X.LT.Y) )
Finally, equality and inequality of intervals are defined by viewing
the intervals as sets.
Syntax function
______ ________
X.EQ.Y .TRUE. if xl=yl and xu=yu
X.NE.Y .TRUE. if .NOT. (X.EQ.Y)
Note: "/=" and "==" shall be interchangeable with ".NE." and
".EQ.", respectively.
D. Special Interval Functions
__________________________
The following utility functions shall be provided for conversion from
INTERVAL to REAL, etc.
Syntax function attainable accuracy
______ ________ ___________________
R = INF(X) Lower bound of X
R = SUP(X) Upper bound of X
R = MID(X) Midpoint of X (a floating point approximation)
R = WID(X) R < xu  xl (the value shall be rounded up,
"Width" to be greater than or equal to
the actual value)
R = MAG(X) R < max { xl, xu }
"Magnitude"
 min { xl, xu } if .NOT.(0.IN.X),
R = MIG(X) R <
 0 otherwise.
"Mignitude"
 [min{x}, max{x}] if .NOT.(0.IN.X)
 x.IN.X x.IN.X
Z = ABS(X) Z < 
 [0, max{x}] if (0.IN.X)
 x.IN.X
Range of absolute value
Z = MAX(X,Y) Z < [max {xl,yl}, max {xu,yu}]
Range of maximum
MAX shall be extended analogously
for more than two
arguments.
Z = MIN(X,Y) Z < [min {xl,yl}, min {xu,yu}]
Range of minimum
MIN shall be extended analogously
for more than two
arguments.
N = NDIGITS(X) Number of leading decimal digits that are the same in
xl and xu. n digits shall be counted as the same if
rounding xl to the nearest decimal number with n
significant digits gives the same result as rounding
xu to the nearest decimal number with n significant
digits.
Z = INTERVAL(R,S) Z < [R,S] (see below)
Z = INTERVAL(R) Z < [R,R]
The conversion function INTERVAL shall be an enclosure for the
specified interval, with an ideal enclosure equal to a machine interval
of minimum width that contains the exact mathematical interval in the
specification.
Note: On many machines, INF, SUP, MAG, MIG, ABS, MAX, and MIN
can be exact, if the target is of a type that corresponds to the
input. This is because these functions merely involve storing one
of the endpoints of the interval into the target variable.
Similarly, the conversion function INTERVAL can be exact on such
machines if it specifies conversion from REAL data of
corresponding type.
All of these functions except MAX, MIN, and NDIGITS shall be elemental
functions.
Note regarding conversion of decimal constants: If R or S are
decimal constants, then a conversion error can occur before the
conversion to INTERVAL. For this reason, such quantities
should be input as interval constants (see I/O below), rather
than with the function INTERVAL. For example, in the statement
Z = INTERVAL( 0.500000000000000000000000000123454321),
the constant 0.500000000000000000000000000123454321 will first
be converted to an internal representation equal to 0.5, then
the internal representation of the stored interval is
[0.5,0.5], an interval that does not contain the interval
constant. However, if an interval constant (defined at the
beginning of the I/O section below) is used, the statement
Z = (< 0.500000000000000000000000000123454321>)
causes the internal representation for Z to contain the value
0.500000000000000000000000000123454321.
Note regarding NDIGITS: For example, if X = [0.1996,0.2004],
then three leading decimal digits of this function are the
same, and NDIGITS(X) is equal to 3. This is because, if
.1996 and .2004 are each rounded to the nearest decimal number
with three significant digits, they both round to .200, yet
they round to different fourdigit decimal numbers.
Note: three interval functions, MAG, MIG, and ABS, correspond to
the point intrinsic ABS. The specification of ABS is as the
range of the absolute value function, consistent with the general
principle that the results of interval functions shall contain
the ranges of corresponding point intrinsics. Although "MAG(X)"
is written X in much of the interval literature, it is more
natural in various applications to have ABS(X) denote the range
of the absolute value function.
Note: The function WID(X) shall be upwardly rounded, since it
often appears in convergence criteria of the form WID(X) <
EPS. The criterion is certain to be satisfied if the computed
value WID(X), used in the comparison, is greater than or equal
to the exact value.
E. Interval versions of the intrinsic functions
____________________________________________
General requirements are:
* All Fortran intrinsic functions that accept REAL data shall also
accept INTERVAL data.
* All functions shall return enclosures of the range.
* Those generic intrinsics that are REAL elemental functions shall also
operate as elemental functions with INTERVAL vector data.
Note: The sharpness of the enclosures is not specified, but an
ideal enclosure should be the smallestwidth interval with
machine numbers as endpoints that contains the actual range.
Thus, the only accuracy requirement for interval versions of the
intrinsics mandates that they contain the range of the
corresponding mathematical function over the set of interval
arguments. (In some cases, such as when the argument to the
intrinsic contains a pole of the function, the range will
be the interval [inf,inf].)
IV. INTERVAL I/O
The following are specified:
* the form of INTERVAL constants;
* conversion of INTERVAL constants to internal storage;
* four formats for input and output of INTERVAL values.
The underlying principle is the same as with the four basic operations
and the interval intrinsic functions: the interval result shall contain
the exact mathematical result. Specifically:
* On input, the stored interval shall contain the interval represented by
the character input string.
* On output, the printed interval shall contain the internally
represented interval.
A. Interval Constants
__________________
Both where literal constants are admitted in a program and as input or
output data, INTERVAL's shall be represented by a single REAL or
INTEGER or a pair of REAL's, INTEGER's, or combinations thereof,
beginning with "(<", separated by "," if there are two numbers, and
ending in ">)". For example
(<1,2>), (<1E0,3>), (<1>), and (<.1234D5>)
are all valid INTERVAL constants. An INTERVAL constant specified by a
single number is the same as an INTERVAL constant specified by two
numbers, both of whose endpoints are equal to the single number. When
such a decimal constant is converted to its internal representation, the
internal representation shall contain the decimal constant, regardless of
how many digits are specified by the decimal constant. For example,
upon execution of the statement:
X = (<0.31415926535897932384626433832795028D+01>)
the interval X shall contain the smallestwidth machine interval that
contains the number 3.1415926535897932384626433832795028.
Note: Thus, on machines in which the interval data type X
appearing in the example above contained components with accuracy
that corresponded to less than 35 decimal digits, the interval X
would contain the mathematical number PI.
Note: In contrast, the statement
X = 0.31415926535897932384626433832795028D+01
is allowed, since implicit conversion is allowed. However, the
compiler can first convert the REAL decimal constant to a valid
REAL that may correspond to fewer digits than the original
representation. When this REAL is rounded into an interval, the
resulting interval does not necessarily contain PI.
As a simpler example of this phenomenon, take the assignment
statement
X = 0.500000000000000000000000000123454321
If the internal representation of a real only corresponded to 16
decimal digits, then the righthand side may first be rounded to
the binary equivalent of
0.5000000000000000.
The interval X would then be the binary equivalent of
(<0.5000000000000000,0.5000000000000000>),
and X would not contain the original righthandside. To
guarantee X contains the actual righthand side, the statement
X = (<0.500000000000000000000000000123454321>)
should be used.
B. The Interval VF Edit Descriptor
_______________________________
The VF edit descriptor is of the form VF.. Here, is meant to
be the width of each of the two numeric fields of the output or input,
and is the number of units to the right of the decimal place in each
of the two output fields. Formally, an output field for a VF.
edit descriptor is of the form , where
1) vfoutputfield is ()
2) foutputfield is the output field for the F.
format, where and are the
values specified in the VF.
edit descriptor.
The value corresponding to foutputfield_sub1 shall be less than or
equal to the exact lower bound of the corresponding output list item,
regardless of the number of digits in the field and number of digits in
the internal representation. The value corresponding to
foutputfield_sub2 shall be greater than or equal to the exact upper
bound of the corresponding output list item, regardless of the number of
digits in the field and number of digits in the internal representation.
It shall be possible to use the VF edit descriptor to output REAL data.
In that case, the value corresponding to foutputfield_sub1 shall be
less than or equal to the exact value of the corresponding real output
list item, regardless of the number of digits in the field and number of
digits in the internal representation. The value of foutputfield_sub2
shall be greater than or equal to the exact upper bound of the
corresponding real output list item, regardless of the number of digits
in the field and number of digits in the internal representation.
An input field for a VF. edit descriptor is of the form
vfinputfield, where
3) vfinputfield is finputfield
or (< finputfield >)
or (< finputfield_sub1, finputfield_sub2 >)
4) finputfield is a valid input field for the F.
format, where and are the
values specified in the VF.
edit descriptor.
If vfinputfield is of the form (< finputfield_sub1,
finputfield_sub2 >), then finputfield_sub1 represents the lower
bound and the finputfield_sub2 represents the upper bound. In this
case, the lower bound of the internal representation of the variable in
the corresponding input item list shall be less than or equal to
finputfield_sub1, and the upper bound of the variable shall be greater
than or equal to finputfield_sub2, regardless of the number of digits
in the field and number of digits in the internal representation.
If vfinputfield is of the form finputfield or (< finputfield >),
then the internal representation of the corresponding variable in the
input item list shall have lower bound that is less than or equal to the
value represented by finputfield, and shall have upper bound that is
greater than or equal to finputfield, regardless of the number of
digits in the field and number of digits in the internal representation.
In ALL interval input fields, blanks between an initial "(<" and the
first numerical fields, blanks to the left and right of a separating
",", and blanks to the left of a closing ">)" shall be ignored.
Examples. Suppose it is required to input the degenerate interval
[1.5,1.5]. Suppose the READ statement is:
INTERVAL X
READ(*,'(1X,VF18.5)') X
Then any of the following input lines results in an internal
representation for X that is equal to or contains the interval
[1.5,1.5].
1.5
or
1.5E0
or
(<1.5>)
or
(<1.5,1.5>)
Note: It is also possible to use singlenumber input to
describe intervals of width 1 unit in the last place exhibited,
and centered on the input value. See the SF edit descriptor
below.
C. The Interval VE Edit Descriptor
_______________________________
VE editing is analogous to VF editing, except that it corresponds to the
E, rather than F, edit descriptor.
The form and interpretation of the input field shall be the same as for
VF editing.
An output field for a VE.[E] edit descriptor shall be of the
form veoutputfield, where
5) veoutputfield is (< eoutputfield_sub1, eoutputfield_sub2 >)
6) eoutputfield is the output field for the E.[Ee]
format, where , , and are the
values specified in the VE.[E]
edit descriptor.
The value corresponding to eoutputfield_sub1 shall be less than or
equal to the exact lower bound of the corresponding output list item,
and the value corresponding to eoutputfield_sub2 shall be greater than
or equal to the exact upper bound of the corresponding output list item,
regardless of the number of digits in the field and number of digits in
the internal representation.
It shall be possible to use the VE edit descriptor to output REAL data.
In that case, the value corresponding to eoutputfield_sub1 shall be
less than or equal to the exact value of the corresponding real output
list item, and the value of eoutputfield_sub2 shall be greater than or
equal to the exact upper bound of the corresponding real output list
item, regardless of the number of digits in the field and number of
digits in the internal representation.
For both input and output, the symbols "(<" , ">)" and "," that are part
of the field shall not be counted as part of the width of the
overall VE field. The total width of the field is thus 2+5.
Example: Suppose an interval variable X is defined in a program,
suppose the program contained the statement
WRITE(*,'(1X,VE12.5E1)') X
and suppose the internal representation of X is that of the interval
(<1.9921875,2.9921875>)}}
Then a valid output produced by the WRITE statement is
(< +0.19921E+1, +0.29922E+1 >)
D. The Interval SE and SF Edit Descriptors
_______________________________________
The SE and SF formats are for single number output of INTERVAL's, with
an implied error of plus or minus .5 units in the last exhibited digit.
Note: In a decimal representation, a number with an implied
error of plus or minus .5 units in the last exhibited digit
corresponds to the set of decimal numbers that are rounded
into the exhibited number.
The basic representation of an INTERVAL as a single number is as
follows:
a) A single number without a decimal point shall represent an
interval whose lower and upper endpoints are identical
(a degenerate, i.e. a point interval).
b) A single number with a decimal point shall represent
an interval whose endpoints are constructed by subtracting
and adding .5 units in the last exhibited decimal digit.
Examples. Here are some intervals represented by single numbers:
Single Number Interval represented
(<.1>) [0.05,.15]
(<1>) [1, 1]
(<.1000>) [.09995, .10005]
(<1E1>) [0.1,0.1]
(<.0>) [.05,.05]
(<0.E3>) [0.5E3, 0.5E3]
The SE and SF specifiers have the same form as the E and F specifiers,
i.e. SF. and SE.[E]. However, the output of an SE or SF
specifier shall be of the form
()
where singlenumberoutput is of the form specified by F. for the
SF. specifier, and of the form specified by E.[E] for the
SE.[E] specifier, with the following differences:
* Only those leading digits that are equal in the left and right
endpoints of the internally represented interval, in the sense
above, shall be printed.
* For zerowidth intervals, neither a decimal point nor digits past the
decimal point shall be displayed.
* For the SF specifier, the positions defined in the descriptor that
correspond to digits that are not displayed shall be filled by blanks,
so the displayed digits are justified as though all digits prescribed by
the specifier were printed. For the SE specifier, if only s digits are
printed, the output will be in the form of an E. specifier,
leftjustified in the field that it would occupy if s were equal to d.
* If a number is too inaccurate to be represented within a specified
SF format, the entire field will be filled with asterisks.
Note: The "SF" format, when used for zerowidth intervals, is
limited to integers., since all other zerowidth intervals will
be output as fields of asterisks.
Note: The specifies the width of the numerical field, and
not the spaces taken by "(<" and ">)". Thus, the total width of
an SE or SF field is +4.
The input for an SE or SF specifier shall be of the form
sfinputfield, where:
sfinputfield is finputfield
or (< finputfield >)
finputfield is a valid input field for the F.
format, where and are the
values specified in the SF.
or SE[E] edit descriptor.
Upon input, the internal representation shall depend upon whether the
input string contains a decimal point. If the input string contains a
decimal point, the number shall be equal to or contain the interval
centered upon the number represented by finputfield, and with width
equal to one decimal unit in the least significant digit exhibited. If
the input does not contain a decimal point, the internal representation
shall be the same as if a VF format specifier is used.
Examples. Suppose the number 1.5 is known to be correct to the
last digit represented, to within rounding.
Suppose the READ statement is:
INTERVAL X
READ(*,'(1X,SF18.5)') X
Then any of the following input lines result in an internal
representation for X that is equal to or contains the interval
[1.45,1.55].
1.5
or
1.5E0
or
(<1.5>)
However, the following inputs merely result in an internal
representation for X that is equal to or contains the degenerate
interval [1.5,1.5].
15E1
or
(<15E1>)
In a second example, inputs of
0.E1
or
(<0.E1>)
or
0.0E2
or
(<0.0E2>)
result in an internal representation for X that contained the interval
[5,5].
Note: In single number interval I/O, input immediately followed
by output can appear to suggest that a decimal digit of accuracy
has been lost, when in fact radix conversion has caused a 1 ulp
increase in the width of the interval stored in the machine. For
example, an input of 0.100 followed by an immediate print will
result in 0.10. Users and implementers need to expect this
behavior.
E. The Interval SG and VG Edit Descriptors
_______________________________________
(i) The interval SG edit descriptor
_______________________________
The interval SG edit descriptor is for general singlenumber interval
input and output.
For input, the SG edit descriptor is identical to the SF edit
descriptor.
The form of the interval SG descriptor is SGw.d or SGw.dEe, where w is
the width of the field and d is the maximum number of digits actually
displayed. The method of representation of the output field depends
both on the magnitude of the datum being edited and on the number of
digits that are equal in the lower bound and upper bound. Define the
following:
Round a lower and upper bound to s significant decimal digits.
Then if all s digits agree, the s digits are said to
CORRESPOND.
Let r be the minimum of d and q, where q is less than or equal
to the maximum number of significant digits of the internal
representation that correspond.
If at least one decimal digit of the lower bound and upper bound
correspond then the number printed by the SGw.d or SGw.dEe formats
shall be the same as that printed by the respective Gw.r and Gw.rEe
formats. The printed number is preceded by the string "(<" and is
followed by the string ">)".
In determining the number of digits that correspond, the lower and upper
bounds of the internal representation may first be converted to a
decimal number in such a way that the converted lower bound is less than
or equal to the lower bound of the internal representation and the
converted upper bound is greater than or equal to the upper bound of the
internal representation. In any case, the number actually printed shall
have r digits that are equal to the r most significant decimal digits of
the lower bound and upper bound of the internal representation.
Note: Ideally, the number of digits determined to correspond
should be the number of digits that actually are equal (in the
sense of rounding in the last digit) in the internal
representation.
If no digits correspond in the above sense, then the output is the same
as with an SEw.0 or SEw.0Ee edit descriptor, leftjustified in
the field.
Example. If the internal representation equals (<1,100>), then an
SG12.5E1 edit descriptor can result in output of the form
(<0.E3 >)
This output is interpreted as the interval [500,500].
(ii) The interval VG edit descriptor
_______________________________
The interval VG edit descriptor is identical to the SF edit descriptor
for input. For output with VGd.w or VGd.wEe, two decimal numbers are
printed, preceded by "(<", separated by ",", and followed by ">)".
The formats of the lower bound and upper bound are determined in
accordance with the rules for Gd.w or Gd.w.Ee editing respectively, as if
the lower bound and upper bound were REAL output. However, the printed
lower bound shall be less than or equal to the lower bound of the
internal representation, and the printed upper bound shall be greater
than or equal to the upper bound of the internal representation.
F. Other Interval I/O
__________________
It shall also be possible to input and output INTERVAL data with the E
and / or F edit descriptors. In that case, two E or F fields, or one of
each, are required for each INTERVAL datum, and the lower and upper
bounds of the INTERVAL datum are treated as usual REAL data.
Note: Warning: In this case the printed interval endpoints may
not contain the internal representation.
Intervals may be also be input and output with a "G" edit descriptor.
Input of an INTERVAL with the G edit descriptor shall be identical to
input with the SF edit descriptor. Output of an interval with a "G"
edit descriptor shall be identical to output with an "SG" edit
descriptor if one or more digits of the internal representation
correspond, and shall be identical to output with the "VG" edit
descriptor otherwise.
Note: The reason the "G" format favors VG when no digits
correspond is because the resulting ideal output interval has a
smaller width in this case. For example, if the internal
representation is [1,2], an SG output gives an interval that
contains (<0.E1>) = [5,5], whereas the output corresponding to
a VG specifier can be exact.
INTERVAL's can also be input and output with NAMELIST and listdirected
I/O.
Output of intervals in listdirected I/O shall be identical to output
with a "G" edit descriptor, with reasonable, processordependent values
of , , and .
G. An Example
__________
The following program implements a onedimensional interval Newton
method to enclose a solution to x**2  4, beginning with starting
interval [1,2].
PROGRAM INTERVAL_NEWTON_ITERATION_1_D
IMPLICIT NONE
REAL(KIND=KIND(0.0D0)) :: XP
INTERVAL :: X, X_IMAGE
INTEGER K
REAL(KIND=KIND(0.0D0)) :: WIDTH_OF_X, OLD_WIDTH
CALL SIMINI
WIDTH_OF_X = 4
X = INTERVAL(1,2)
DO K = 1,10000
OLD_WIDTH = WIDTH_OF_X
WIDTH_OF_X = WID(X)
XP = MID(X)
WRITE(*,*) K, INF(X),SUP(X), XP, WIDTH_OF_X, WIDTH_OF_X/OLD_WIDTH**2
X_IMAGE = XP  ( INTERVAL(XP)**2INTERVAL(4) ) / (2*X)
IF(WIDTH_OF_X.LT.1D11) EXIT
X = X_IMAGE
END DO
END PROGRAM INTERVAL_NEWTON_ITERATION_1_D
The output for this program can be:
Columns 1 through 4:
1 0.9999999999999998 2.0000000000000004 1.5000000000000000
2 1.9374999999999991 2.3750000000000018 2.1562500000000004
3 1.9886592741935472 2.0195312500000009 2.0040952620967740
4 1.9999724292486507 2.0000354537727549 2.0000039415107027
5 1.9999999999417792 2.0000000000659868 2.0000000000038831
6 1.9999999999999989 2.0000000000000009 2.0000000000000000
Columns 5 and 6:
1.0000000000000009 6.2500000000000056E02
0.4375000000000028 0.4375000000000020
3.0871975806453740E02 0.1612903225806542
6.3024524104227111E05 6.6127289936492972E02
1.2420753314756896E10 3.1270065174661590E02
1.9984014443252822E15 1.2953492022672087E+05
Note: The new iterate is contained in the interior of the old
iterate between steps 2 and 3. This constitutes a mathematical
proof that there is a unique solution of x**24 = 0 within
iterate 2, and hence within iterate 3, and all subsequent
iterates will contain this solution.
For the VE format, replace the line:
WRITE(*,*) K, INF(X),SUP(X), XP, WIDTH_OF_X, WIDTH_OF_X/OLD_WIDTH**2
by:
WRITE(*,'(1X,I2,1X,VE10.4E1,3(1X,E12.4E2))') &
K, X, XP, WIDTH_OF_X, WIDTH_OF_X/OLD_WIDTH**2
The output is then:
1 (< 0.9999E+0, 0.2001E+1 >) 0.1500E+01 0.1000E+01 0.6250E01
2 (< 0.1937E+1, 0.2376E+1 >) 0.2156E+01 0.4375E+00 0.4375E+00
3 (< 0.1987E+1, 0.2020E+1 >) 0.2004E+01 0.3087E01 0.1612E+00
4 (< 0.1999E+1, 0.2001E+1 >) 0.2000E+01 0.6302E04 0.6612E01
5 (< 0.1999E+1, 0.2001E+1 >) 0.2000E+01 0.1242E09 0.3127E01
6 (< 0.1999E+1, 0.2001E+1 >) 0.2000E+01 0.1998E14 0.1295E+05
For the SE format, replace the WRITE statement by
WRITE(*,'(1X,I2,1X,SE10.4E1,3(1X,E12.4E2))') &
K, X, XP, WIDTH_OF_X, WIDTH_OF_X/OLD_WIDTH**2
The output is then:
1 (< 0.E+1 >) 0.1500E+01 0.1000E+01 0.6250E01
2 (< 0.2E+1 >) 0.2156E+01 0.4375E+00 0.4375E+00
3 (< 0.20E+1 >) 0.2004E+01 0.3087E01 0.1612E+00
4 (< 0.2000E+1 >) 0.2000E+01 0.6302E04 0.6612E01
5 (< 0.2000E+1 >) 0.2000E+01 0.6302E04 0.6612E01
6 (< 0.2000E+1 >) 0.2000E+01 0.6302E04 0.6612E01
For the SF format, replace the WRITE statement by
WRITE(*,'(1X,I2,1X,SF18.15,3(1X,E12.4E2))') &
K, X, XP, WIDTH_OF_X, WIDTH_OF_X/OLD_WIDTH**2
The output is then:
1 (<******************>) 0.1500E+01 0.1000E+01 0.6250E01
2 (< 2. >) 0.2156E+01 0.4375E+00 0.4375E+00
3 (< 2.0 >) 0.2004E+01 0.3087E01 0.1612E+00
4 (< 2.0000 >) 0.2000E+01 0.6302E04 0.6612E01
5 (< 2.000000000 >) 0.2000E+01 0.1242E09 0.3127E01
6 (< 2.00000000000000 >) 0.2000E+01 0.1998E14 0.1295E+05
The number of digits printed in this case is the number of digits known
to be correct, assuming the actual number, displayed as an infinite
decimal sequence, has been rounded into the displayed digits by rounding
to nearest.
For the SE format, replace the WRITE statement by
WRITE(*,'(1X,I2,1X,SG18.15,3(1X,E12.4E2))') &
K, X, XP, WIDTH_OF_X, WIDTH_OF_X/OLD_WIDTH**2
and the output can be:
1 (< 0.E+1 >) 0.1500E+01 0.1000E+01 0.6250E01
2 (< 2. >) 0.2156E+01 0.4375E+00 0.4375E+00
3 (< 2.0 >) 0.2004E+01 0.3087E01 0.1612E+00
4 (< 2.0000 >) 0.2000E+01 0.6302E04 0.6612E01
5 (< 2.000000000 >) 0.2000E+01 0.1242E09 0.3127E01
6 (< 2.00000000000000 >) 0.2000E+01 0.1998E14 0.1295E+05
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
V. ADDITIONAL NOTES (not part of proposal proper)
A. On Optimization of Interval Expressions
_______________________________________
Optimizing compilers generally attempt to reduce the total number of
point operations. However, since interval arithmetic is only
subdistributive, there are additional issues in optimizing interval
expressions. For example,
(<0,1>)**2  (<0,1>)
evaluates to
(<0,1>)  (<0,1>) = (<1,1>),
while
(<0,1>) * ((<0,1>)(<1,1>))
evaluates to
(<0,1>) * (<1,0>) = (<1,0>).
However, both (<1,1>) and (<1,0>) are bounds on the range of x**2x
over (<0,1>). We want to transform x**2x to x*(x1) in this case, or
else compute the expression BOTH ways and take the intersection, to
obtain the smallest possible enclosure to the range of x**2  x over
(<0,1>). Such rewriting should be possible with modifications of
existing optimizing compiler technology.
B. Can Interval Arithmetic be Implemented Effectively in a Module?
_______________________________________________________________
The following items appear central to this question:
* INTERVAL constants are not implementable in a module.
* The I/O edit descriptors cannot be defined in a module.
* The precedence of the new infix operators cannot be defined in a
module.
* There is an efficiency issue.
Although edit descriptors in Fortran 95 are fixed, INTERVAL I/O can be
defined in a module through subroutines. Furthermore, derivedtype I/O,
discussed for Fortran 2000, would ameliorate the situation with I/O
descriptors, should derivedtype I/O materialize.
There is no way other than intrinsic language support to allow INTERVAL
constants in program statements. INTERVAL constants can be supported in
module subroutines for input and output.
However, a crucial property of such constants cannot be easily
implemented in a module. Namely, the proposal stipulates that conversions
to and from internal representations shall contain the original results,
regardless of the number of digits present in the internal
representation or the number of digits in the decimal constant or format
item.
Regarding efficiency: Usersupplied modules for interval arithmetic
contain subroutines for each of the four arithmetic operations and for
the other infix operators. At least one existing compiler translates
each elementary operation to a subroutine call to the corresponding
subroutine. The resulting machine code executes 20 or more times more
slowly than point arithmetic, although factors of five or even two are
often practical. It can be argued that an optimizing compiler will
inline short subroutines. The concept of an INTRINSIC MODULE, that is,
a module supplied by the manufacturer and bundled with the compiler, has
been put forward for Fortran 2000. Presumably, with an intrinsic
module, there would be essentially no difference between implementation
of interval arithmetic intrinsically in the language and as a module,
except that access to the interval arithmetic would be enabled through a
"USE" statement. However, we are unaware of inlining Fortran
compilers, and intrinsic modules have not yet materialized as part of
the language.
There is a natural operator precedence for the INTERVAL operators that
differs from that for userdefined operators in Fortran 90 (i.e.
userdefined binary operations always have the lowest precedence). This
order, followed in aACRITHXSC, is:
Numeric **
Numeric *, /, .IS.
Numeric unary + or 
Numeric binary + or , .CH.
Character //
Relational .EQ.,.NE.,.LT.,.LE.,.GT.,.GE.,.SB.,.SP.,.DJ.,.IN. .
==, /=, <, <=, >, >=
Logical .NOT.
Logical .AND.
Logical .OR.
Logical .EQV. or .NEQV.
At present, such an ordering can be defined only intrinsically in the
language, not through a module.
=====================_828735018==_
ContentType: text/plain; charset="usascii"

R. Baker Kearfott, rbk [at] usl [dot] edu (318) 4825346 (fax)
(318) 4825270 (work) (318) 9819744 (home)
URL: ftp://interval.usl.edu/pub/interval_math/www/kearfott.html
Department of Mathematics, University of Southwestern Louisiana

=====================_828735018==_
From ownerreliable_computing Mon Apr 8 17:19:53 1996
Received: by interval.usl.edu id AA11171
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 9 Apr 1996 00:20:03 0500
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA11165
(5.65c/IDA1.4.4 for ); Tue, 9 Apr 1996 00:20:00 0500
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA20220; Mon, 8 Apr 96 23:19:53 MDT
Date: Mon, 8 Apr 96 23:19:53 MDT
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9604090519.AA20220 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: Kearfott's paper on the web
Sender: ownerreliable_computing
Precedence: bulk
Dear Friends,
Baker Kearfott's survey paper
"Interval Computations: Introduction, Uses, and Resources"
(submitted to the EuroMath Bulletin),
is now accessible from the interval website;
Both postscript and dvi versions are explicitly
mentioned in the main menu
URL http://cs.utep.edu/intervalcomp/main.html
Vladik
From ownerreliable_computing Tue Apr 9 05:48:35 1996
Received: by interval.usl.edu id AA12195
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 9 Apr 1996 14:49:33 0500
Received: from hplabs.hpl.hp.com by interval.usl.edu with SMTP id AA12189
(5.65c/IDA1.4.4 for ); Tue, 9 Apr 1996 14:49:15 0500
Received: from msd.hpl.hp.com by hplabs.hpl.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3+HPL1.1SU) id AA115489316; Tue, 9 Apr 1996 12:48:36 0700
Received: by msd.hpl.hp.com
(1.39.111.2/15.5+ECS 3.3+HPL1.1) id AA021219316; Tue, 9 Apr 1996 12:48:36 0700
From: "Lee Barford"
MessageId: <9604091248.ZM2119 [at] msd [dot] hpl.hp.com>
Date: Tue, 9 Apr 1996 12:48:35 0700
ReplyTo: barford [at] hplabs [dot] hpl.hp.com
XMailer: ZMail (3.2.1 15feb95)
To: reliable_computing [at] interval [dot] usl.edu
Subject: Wanted: solutions to interval eigenvalue problems
MimeVersion: 1.0
ContentType: text/plain; charset=usascii
Sender: ownerreliable_computing
Precedence: bulk
I would appreciate receiving pointers to research concerning computing interval
* eigenvalues of real symmetric interval matrices or
* singular values of general complex interval matrices.
I am most interested in hearing about work in progress or unpublished research,
as I am also doing a literature search on these topics.
Regards,
Lee Barford

Lee A. Barford barford [at] hpl [dot] hp.com Voice: 4158573606
HewlettPackard Laboratories 4AD FAX: 4158528092
POB 10151
Palo Alto, CA 943030889 http://www.hpl.hp.com/personal/Lee_Barford
From ownerreliable_computing Wed Apr 10 15:07:28 1996
Received: by interval.usl.edu id AA12741
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 10 Apr 1996 02:44:27 0500
Received: from fermat.pdmi.ras.ru by interval.usl.edu with SMTP id AA12735
(5.65c/IDA1.4.4 for ); Wed, 10 Apr 1996 02:43:49 0500
Received: from gem.UUCP (uucp@localhost) by fermat.pdmi.ras.ru (8.6.12/8.6.12) with UUCP id LAA01705 for reliable_computing [at] interval [dot] usl.edu; Wed, 10 Apr 1996 11:38:42 +0400
Received: by gem.pdmi.ras.ru (UUPC/@ v5.09gamma, 14Mar93);
Wed, 10 Apr 1996 11:07:28 +0400
To: reliable_computing [at] interval [dot] usl.edu
References: <199603142315.AA16196 [at] bp [dot] ucs.usl.edu>
MessageId:
Organization: Steklov Mathematical Institute / GEM Computer
From: "Eldar A. Musaev"
Date: Wed, 10 Apr 96 11:07:28 +0400
Subject: The journal "Reliable Computing": please, show this special offer to your librarian
XMailer: BML [MS/DOS Beauty Mail v.1.36]
Lines: 210
Sender: ownerreliable_computing
Precedence: bulk
Special 15% discount offer Valid till December 31st, 1996
 
International Journal
***** *****
RELIABLE COMPUTING
***** *****

*** Complete back subscriptions limited offer ***

A refereed international journal, RELIABLE COMPUTING is the only
periodical in the world devoted specifically to various aspects of
reliable mathematical computations based on finite representations of
mathematical objects, and giving a guaranteed accuracy of computed
results. It is managed by an international editorial board from Bulgaria,
Germany, Japan, Russia, and the United States, and printed in Russia. The
journal is distributed in approximately 30 countries throughout the
world. It includes various items in the fields of theoretical research,
computer tools, applications, interdisciplinary research, and other
relevant areas in the field of mathematical computations with the use of
a computer. The following subjects are within the focus of the journal:
numerical, symbolic and combined algorithms for solving computational
problems, the interval approach, computer architecture for mathematical
computations, contemporary languages for mathematical processes
description, methods of localization of solutions, teaching of reliable
computational methods at universities, etc. "Reliable Computing" also
publishes proceedings of international conferences, such as INTERVAL'XX,
SCAN'XX, etc.
The editorial policy is based on the fruitful experience of 4 years
of publishing the journal "Interval Computations", and continues its best
traditions, but now it is not restricted to the interval approach.
Additionally, many enhancements has been made in the journal's
typesetting and layout, and its size is now larger. We hope the widened
scope of our journal will attract a wider circle of readers.
Consistent with the policy of "Interval Computations," the
languages of publication are English and Russian, with at least 90% of
the items in English. All articles are provided with abstracts in both
languages.
Papers published in "Reliable Computing" are listed in wellknown
abstracting and bibliographic journals, i.e. "Mathematical Reviews",
"Referativnyi Zhurnal VINITI" and others.
The journal includes:
o original papers
o surveys and tutorials
o reports on new computer tools
o bibliographies
o reviews of new books
o letters to the editor
o information about scientific meetings
All published issues of "Interval Computations" and "Reliable
Computing", excluding No 1/1991, are available for purchase (see the
section below).
Additionally, Supplementum 1, consisting of a "Bibliography of
Works on Interval Computations Published in Russian", with a subject
index, is now available. It includes almost all sensible references in
the field (547 items in the current version) in English translation.
In addition, the Editorial Board has published the collection of
abstracts of the International Conference on Interval and Computer
Algebraic Methods in Science and Engineering (Interval'94), which was
held in St.Petersburg, Russia, March 710, 1994. Abstracts are in
English, two pages average, including postal and email addresses of the
authors (total 226 p.).
EDITORIAL BOARD
The Editorial Board of "Reliable Computing" includes:
G. ALEFELD Karlsruhe, Germany
B. S. DOBRONETS Krasnoyarsk, Russia
R. B. KEARFOTT Lafayette, LA, USA  official representative in
the Western Hemisphere
V. KREINOVICH El Paso, TX, USA
S. M. MARKOV Sofia, Bulgaria
E. A. MUSAEV St. Petersburg, Russia  Executive Editor
M. T. NAKAO Fukuoka, Japan
V. M. NESTEROV St. Petersburg, Russia  EditorinChief
H. RATSCHEK Dusseldorf, Germany
S. M. RUMP Hamburg, Germany
A. L. SEMENOV Moscow, Russia
S. P. SHARY Novosibirsk, Russia
J. WOLFF VON
GUDENBERG Wuerzburg, Germany  official representative in
Europe
A. G. YAKOVLEV Moscow, Russia  Managing Editor
V. S. ZYUZIN Saratov, Russia
The address of the Editorial Board:
Box 52
St.Petersburg 195256, Russia
Phone: +78125344120
Fax: +78122344852
Email: nest [at] nit [dot] spb.su (preferable), intcom [at] glas [dot] apc.org
SUBSCRIPTION INFORMATION *** SPECIAL LIMITED OFFER ***
*** VALID TILL DECEMBER 31ST, 1996 ***
This special offer is aimed specially at university libraries and
other institutions interested in getting a COMPLETE BACK SUBSCRIPTIONS SET
of the journal. For individual subscriptions, please contact regional
representatives. All indicated prices include postage.
Regular prices for complete back sets for:
#2 for 1991 (#1 is N/A) US$ 30.00 DM 42.00
1992 (4 issues) US$ 120.00 DM 168.00
1993 (4 issues) US$ 120.00 DM 168.00
1994 (4 issues) US$ 120.00 DM 168.00
1995 (4 issues) US$ 120.00 DM 168.00
Supplementum 1 US$ 20.00 DM 28.00
Interval'94 abstracts US$ 30.00 DM 42.00

Total: US$ 560.00 DM 784.00
+ For institutions only! +
 Save 15% and get a complete set! 
Special limited offer: 
from 1991 to 1995 including 
Suppl. 1 and Interval'94 
abstracts ! 
 Total: US$ 476.00 DM 667.00 
++
Regular subscription:
1996 (4 issues) US$ 120.00 DM 168.00
If you wish to use benefits of this special offer or just subscribe
to "Reliable Computing" and/or receive the Supplements, please send this
order form, along with a check for the appropriate amount (or use a bank
transfer), to one of our official representatives:
Payment in US$: Payment in DM:
Dr. R. Baker Kearfott Prof. Dr. J. Wolff von Gudenberg
Department of Mathematics Lehrstuhl f. Informatik II
Univ. of Southwestern Louisiana Universitaet Wuerzburg
U.S.L. Box 41010 Lafayette Am Hubland
LA 705041010 Wuerzburg D97074
USA Germany
Office: (318) 2315270 Phone: +499318885517
Home: (318) 9819744 Fax: +499318884602
Email: rbk [at] usl [dot] edu Email: wolff [at] informatik [dot] uni
wuerzburg.de
Please make a check to Instructions for bank transfer:
the "University of holder: J. Wolff v. Gudenberg
Southwestern Louisiana" number: 560219826
bank: Kreissparkasse Wuerzburg
bank code: 790 501 30
ATTENTION: up to 1994, the journal was published under the
title "Interval Computations"

"RELIABLE COMPUTING" ORDER FORM
Name: ________________________________________________________________
Organization: ________________________________________________________
Address: _____________________________________________________________
______________________________________________________________________
State: _______________________________ Zip: __________________________
Tel.: __________________ (optional) Fax: __________________ (optional)
Email: __________________________________________ (highly desirable!)
[ ] Please accept the subscription for the journal "Reliable
Computing" for:
Back sets:
[ ] #2 1991 (#1 N/A) US$ 30.00 DM 42.00
[ ] 1992 (4 issues) US$ 120.00 DM 168.00
[ ] 1993 (4 issues) US$ 120.00 DM 168.00
[ ] 1994 (4 issues) US$ 120.00 DM 168.00
[ ] 1995 (4 issues) US$ 120.00 DM 168.00
Regular subscription:
[ ] 1996 (4 issues) US$ 120.00 DM 168.00
Supplements:
[ ] Supplementum 1 US$ 20.00 DM 28.00
[ ] Interval'94 abstracts US$ 30.00 DM 42.00
[ ] We wish to use your special limited offer for institutions and
save 15% off the regular price:
[ ] #2/1991, all issues from 1992 to 1995 including Suppl. 1
and Interval'94 Abstracts
US$ 476.00 DM 667.00
Sum of __________ paid via [ ] cheque [ ] bank transfer
Date: _______________________ Signature: _____________________
From ownerreliable_computing Sat Apr 13 11:24:49 1996
Received: by interval.usl.edu id AA17728
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Sat, 13 Apr 1996 18:24:56 0500
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA17722
(5.65c/IDA1.4.4 for ); Sat, 13 Apr 1996 18:24:52 0500
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA19843; Sat, 13 Apr 96 17:24:49 MDT
Date: Sat, 13 Apr 96 17:24:49 MDT
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9604132324.AA19843 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: contents of RC Vol. 2, No. 2
Sender: ownerreliable_computing
Precedence: bulk
Reliable Computing.  1996.  N 2 (2).  114 p.
CONTENTS
Preface 95
Mechanising the theory of intervals using OBJ3
Marcilia A. Campos, Augusto C. A. Sampaio, and Alexandre H. F.
Brainer 97
Errors in vector processing and the library libavi.a
Tiaraju A. Diverio, Ursula A. Fernandes, and Dalcidio
M. Claudio 103
Chebyshev acceleration techniques for large complex non
Hermitian eigenvalue problems
Vincent Heuveline and Miloud Sadkane 111
Interval methods that are guaranteed to underestimate (and the
resulting new justification of Kaucher arithmetic)
Vladik Kreinovich, Vyacheslav M. Nesterov, and Nina A. Zheludeva 119
On the computational complexity of the solution of linear
systems with moduli
Anatoly V. Lakeyev 125
Software for high radix online arithmetic
Thomas Lynch and Michael J. Schulte 133
Selfcorrecting polynomial programs
Guevara Noubir and Henri J. Nussbaumer 139
Reducing division latency with reciprocal caches
Stuart F. Oberman and Michael J. Flynn 147
Interval approach challenges Monte Carlo simulation
Janne Pesonen and Eero Hyvonen 155
Interval operations involving NaNs
Evgenija D. Popova 161
Enclosing solutions of overdetermined systems of linear interval
equations
Jiri Rohn 167
Numerical solutions of Burgers' equation with a large Reynolds
number
Masaaki Sugihara and Seiji Fujino 173
Rank of convex combinations of matrices
Tomasz Szulc 181
Locating, characterizing and computing the stationary points of
a function
Michael N. Vrahatis and Evangelia C. Triantafyllou 187
Reviews
Applications of Reliable Scientific Computing 195
Addresses of the Editorial Board members 204
Information for authors 206
Contents 207
The contents of all the issues, as well as other information related to
interval computations, is placed on the Interval Computations website
http://cs.utep.edu/intervalcomp/main.html
(for journal, click on the Journal link in the main menu)
From ownerreliable_computing Sat Apr 20 13:52:49 1996
Received: by interval.usl.edu id AA26256
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Sat, 20 Apr 1996 20:52:58 0500
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA26250
(5.65c/IDA1.4.4 for ); Sat, 20 Apr 1996 20:52:54 0500
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA23473; Sat, 20 Apr 96 19:52:49 MDT
Date: Sat, 20 Apr 96 19:52:49 MDT
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9604210152.AA23473 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: geophysics issue: deadline extended
Sender: ownerreliable_computing
Precedence: bulk
Dear Colleagues,
As you may have noticed from the ad in No. 1, 1996 issue of
Reliable Computing or from the Interval Computations website
http://cs.utep.edu/intervalcomp/main.html
the deadline for the special issue on geophysical applications of interval computations has been
extended to June 1, 1996. Please send your papers
(ideally, in plain LaTeX) to me at vladik [at] cs [dot] utep.edu.
The published ad requires an abstract by April 1, but since the
journal was published with a slight delay and reached most subcribers
after April 1, please ingnore this abstract deadline and
send in your abstracts as soon as they are ready.
Yours
Vladik
From ownerreliable_computing Sun Apr 21 05:55:07 1996
Received: by interval.usl.edu id AA26792
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Sun, 21 Apr 1996 10:55:10 0500
Received: by interval.usl.edu id AA26782
(5.65c/IDA1.4.4 for reliable_computing); Sun, 21 Apr 1996 10:55:07 0500
Date: Sun, 21 Apr 1996 10:55:07 0500
From: "Kearfott R. Baker"
MessageId: <199604211555.AA26782 [at] interval [dot] usl.edu>
To: reliable_computing
Subject: URL confusion
Sender: ownerreliable_computing
Precedence: bulk
Dear Colleagues:
A World Wide Web server has recently been installed on
"interval.usl.edu." Although this should allow more convenient access
than the FTP site to some things, it has caused some confusion. The
FTP site is still active, and can be still be accessed, but the proper
URL must be used. Here are some examples of URL's that can be given to
a Web browser such as Netscape:
CORRECT:
http://interval.usl.edu/preprints.html
CORRECT:
ftp://interval.usl.edu/pub/interval_math/
INCORRECT:
http://interval.usl.edu/pub/interval_math/
Some, but not all, items available via FTP are also available through
the web server protocol, and there are some items available through the
web server protocol that are not available via FTP. I will continue to
develop the web server items as appropriate. Please tell me of any
problems, and I apologize for any inconvenience.

R. Baker Kearfott, rbk [at] usl [dot] edu (318) 4825346 (fax)
(318) 4825270 (work) (318) 9819744 (home)
URL: http://interval.usl.edu/kearfott.html
Department of Mathematics, University of Southwestern Louisiana

From ownerreliable_computing Wed Apr 24 13:54:53 1996
Received: by interval.usl.edu id AA28876
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 24 Apr 1996 20:55:06 0500
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA28870
(5.65c/IDA1.4.4 for ); Wed, 24 Apr 1996 20:55:03 0500
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA02535; Wed, 24 Apr 96 19:54:53 MDT
Date: Wed, 24 Apr 96 19:54:53 MDT
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9604250154.AA02535 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: Proceedings of SCAN95
Sender: ownerreliable_computing
Precedence: bulk
Akademie Verlag
Scientific Computing and Validated Numerics
Proceedings of the International Symposium on Scientific Computing, Computer
Arithmetic and Validated Numerics SCAN95, held in Wuppertal
Goetz Alefeld / Andreas Frommer / Bruno Lang (Eds.)
Mathematical Research, Volume 90
1996. 340 S.  31 Abb.  20 Tab.  170 x 240 mm
Pb, DM/sFr 130, oS 962,
ISBN 3055017374
Editors' affiliations:
Goetz Alefeld, Professor of Applied Mathematics, University of Karlsruhe;
Andreas Frommer, Professor of Applied Computer Science,
University of Wuppertal;
Bruno Lang, Dr. rer. nat., University of Wuppertal
Target groups: Applied mathematicians, numerical analysts, specialists in
computer science
The International Symposium on Scientific Computing, Computer Arithmetic and
Validated Numerics SCAN is held biannually, the fourth conference took place
in Wuppertal 1995.
This volume contains contributions from outstanding research specialists
based on their presentations at SCAN95. It covers all aspects of scientific
computing with validation, starting with the latest developments in the
design of floating point units together with algorithms for floating point
operations and elementary function evaluations with maximum accuracy. The
book continues by treating scientific computing methods for many areas of
applied mathematics such as numerical linear algebra, nonlinear equations,
global optimization, ordinary and partial differential equations and
dynamical systems. Some computer science aspects like complexity are also
considered as are examples where validation methods have successfully been
used in applications from the engineering sciences.
Contributions by:
G. Alefeld (Karlsruhe), G. Corliss (Milwaukee) and R. Rihm (Karlsruhe), N.
Dimitrova (Sofia), B. Dobronets (Krasnoyarsk), G. Heindl (Wuppertal), J.
Herzberger (Oldenburg), E. Hyvonen (Espoo), K.U. Jahn (Leipzig), R. B.
Kearfott (Lafayette), V. Kreinovich (El Paso), W. Luther and W. Otten
(Duisburg), M. Vrahatis (Patras), S. Markov (Sofia), G. Mayer (Rostock), M.
Mrozek (Cracow), J.M. Muller and A. Tisserand (Lyon), M. Nakao (Fukuoka),
M. Plum (Karlsruhe), J. Rohn (Prague), S.M. Rump (HamburgHarburg), A.
Semenov (Novosibirsk), S. Shary (Krasnoyarsk), Y. Shokin (Novosibirsk), J.
Wolff von Gudenberg (Wrzburg)
Short Description: This volume contains the key lectures of SCAN95. It
treats latest results in all areas of scientific computing with validation
including hardware, elementary operations and functions, numerical methods
and applications from the engineering sciences.
Copies can be ordered by email from
reiher@akademieverlag.de (Mrs. Reiher) or
mktg@akademieverlag.de (Marketing Department)
Information on the book can found on URL
http://www.vcgroup.de/akademieverlag/books/mathphys.html#Scientific
From ownerreliable_computing Wed Apr 24 14:39:51 1996
Received: by interval.usl.edu id AA29185
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 24 Apr 1996 21:39:57 0500
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA29179
(5.65c/IDA1.4.4 for ); Wed, 24 Apr 1996 21:39:54 0500
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA02720; Wed, 24 Apr 96 20:39:51 MDT
Date: Wed, 24 Apr 96 20:39:51 MDT
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9604250239.AA02720 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: SCAN 95 Proceedings
Sender: ownerreliable_computing
Precedence: bulk
Re Proceedings of SCAN95 edited by G. Alefeld, A Frommer, and B. Lang:
1) There was a typo in the book's URL; I apologize for it; the correct
URL is
http://www.vchgroup.de/akademieverlag/books/mathphys.html#Scientific
2) We have placed a mirror image of this page in the Books section of
the Interval Computations website; to get to this section, click on
Books in the main page
URL http://cs.utep.edu/intervalcomp/main.html
3) Just a reminder: some papers presented at the SCAN95 conference are
published in a special issue of Reliable Computing (Vol. 2, No. 2,
1996). Subscribers will get this issue among others.
Detailed contents of this issue
and order forms for nonsubscribers can also be found on the
Interval Computations website.