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 (DOM_FLOAT).
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 DOM_INTERVAL is 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 + or * is the smallest representable interval containing the exact result. In other words, operations on DOM_INTERVAL are locally optimal.
Note that the representation of an element of DOM_INTERVAL on 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 Dom::FloatIV.
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 operands:
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:
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 infinity or -infinity into an interval of type DOM_INTERVAL, the resulting interval will contain the corresponding floating-point infinity, which are displayed as RD_INF or RD_NINF, respectively:
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 DOM_INTERVAL is 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 details.
As of version 2.5, MuPAD implements the following operations on elements of type DOM_INTERVAL:
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 DOM_INTERVAL may be a union of rectangles in the complex plane. In this case, the 0th operand is the identifier union, while the remaining operands are the corresponding rectangles, which are of type DOM_INTERVAL.
Rectangles with non-zero imaginary part, which are not unions, have two operands of type DOM_INTERVAL: 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 ... right", 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:
hull(PI, -3, 1/2), hull(1/3)
1 ... 4+I
The function interval creates elements of type DOM_INTERVAL as well, but may return expressions:
Note that floating-point values in the input of hull or 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 because hull cannot 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: