Floating point intervals
Object of type
DOM_INTERVAL represents an
interval of complex numbers. Either border may be infinity or -
∞. The borders are represented by floating
point numbers (
Objects of type
DOM_INTERVAL represent numerical
enclosures of rectangles in the complex plane or finite unions thereof.
Numerical enclosures of real intervals are an important special case.
The result of all arithmetical operations on elements of type
rounded outwards, that is, the resulting (union of) rectangle(s) is guaranteed to
contain the exact result. If the result interval is purely real, the
lower bound of the result is guaranteed to be no larger than the exact
value of the exact result, while the upper value of the result is
guaranteed to be no smaller than the exact value. The exact values
may not be representable as floating-point numbers. In this case,
the result of a single operation such as
* is the smallest representable
interval containing the exact result. In other words, operations on
Note that the representation of an element of
the screen is generated with outward rounding, too. This may lead
to "apparent overestimation," as you can see in Example 1.
For generating matrix or polynomial rings over floating-point
intervals, use the façade domain
An interval of type
DOM_INTERVAL can only
hold floating-point numbers, which are internally stored as binary
numbers. For this reason, it cannot hold symbolic expressions as its
iv := hull(PI)
This intervals certainly does contain π.
However, the value printed on the screen does not accurately describe
the interval generated, as you can see when you print the same interval
with a larger value of
DIGITS := 15: iv; delete DIGITS:
In the first output, it looked as if the difference between the two borders (the width of the interval) was 10- 8, while in the latter output we can see that it is at most 10- 13. Actually, the difference is even smaller:
op(iv,2) - op(iv,1)
This rounding does not take place for symbolic values which can be represented exactly in both the internal (binary) and the on-screen (decimal) format:
iv := hull(1); op(iv,2) - op(iv,1)
However, floating-point values in the input are assumed to be approximations up to the current computing precision:
iv := hull(1.0); op(iv,2) - op(iv,1)
If you convert
an interval of type
DOM_INTERVAL, the resulting
interval will contain the corresponding floating-point infinity, which
are displayed as
Since the range of floating-point numbers is limited, also conversion of finite values may generate floating-point infinities. The exact limit of floating-point numbers may change from one MuPAD® version to the next. Currently, the following command exceeds the representable range::
As for calculating with intervals with infinities as their borders, note that any multiplication where one factor is exactly zero and the other factor contains either infinity results in the interval encompassing the whole real axis:
(0...0) * (1e30...infinity)
Objects of type
DOM_INTERVAL represent rectangular
subsets of the complex plane with the sides parallel to the coordinate
axes or unions of such rectangles. In the following example, the exact
result would be a rotated rectangle. Interval arithmetics returns
the smallest non-rotated rectangle enclosing the precise result:
When computing with floating-point numbers, you can easily run into cancellation and round-off errors without noticing:
(1+1e-18) - 1.0
The fundamental problem of numerical computations is that there is no indication to these errors. Of course, you can get around most problems of this type by increasing the number of significant digits, if you know that problems are lurking:
DIGITS:=50: (1+1e-18) - 1.0, sin(1e42)
Interval calculations, amongst other things, provide a way to
be notified of cancellation since the result of an operation over
certain to contain the exact result:
DIGITS:=10: (1+1e-18) - hull(1.0)
So, in the latter case we know that the first 17 digits are correct and that the 18th digit is 3, 4, or 5.
The result of a call to an interval is the interval itself, regardless of the arguments. The arguments are not evaluated.
You can access the borders of an interval using
op. See below for the
As of version 2.5, MuPAD implements the following operations
on elements of type
For legal combinations of arguments, all computations are carried out in interval arithmetics, see Example 4.
The operands of an interval depend on its value:
An interval of type
be a union of rectangles in the complex plane. In this case, the 0th
operand is the identifier
while the remaining operands are the corresponding rectangles, which
are of type
Rectangles with non-zero imaginary part, which are
not unions, have two operands of type
Their real and imaginary parts, both of which are real intervals.
Real intervals, i.e., non-union rectangles with vanishing imaginary part, have two operands, their left and right borders.
A real interval is displayed in the form "left
where "left" and "right" are the borders
of the interval, printed as floating-point numbers.
A complex interval is displayed as "(real part) + (imaginary part) * I", with the real and imaginary part displayed as real intervals.
A union of rectangles is displayed as "interval union interval", with the intervals inside written as specified above.
Note that the borders are rounded outwards for printing. Example 1 shows how this effects the output.
Elements of type
DOM_INTERVAL can be constructed
in the following ways:
With the function
hull(PI, -3, 1/2), hull(1/3)
1 ... 4+I
elements of type
DOM_INTERVAL as well, but may
Note that floating-point values in
the input of
interval are considered
to be approximations, even if the value displayed in the decimal system
can be represented exactly in the internal binary format. This is
decide whether, for example, 0.25 has
actually been typed in as such or if it should have been some 0.25
+ ϵ. If you want zero-width
intervals, use a rational number as input which can be represented
exactly in binary:
Intervals of type
DOM_INTERVAL are always
interpreted as closed intervals, i.e., the endpoints
belong to the set. It is reasonable not to have open intervals included,
since most operations will enlarge the resulting interval anyway (although
only marginally so).