Note: This page has been translated by MathWorks. Please click here

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

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.

Because an element of type `DOM_INTERVAL`

contains
floating-point numbers of type `DOM_FLOAT`

, its exact value depends on the
value of the environment variable `DIGITS`

at the time of creation.

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:

hull(infinity), hull(-infinity)

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::

hull(exp(10^9))

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:

(1...2+I)*(1+I)

When computing with floating-point numbers, you can easily run into cancellation and round-off errors without noticing:

(1+1e-18) - 1.0

sin(1e42)

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)

sin(hull(1e42))

DIGITS:=50: sin(hull(1e42))

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.

Intervals can be viewed as sets, and the corresponding functions `union`

, `intersect`

, and `minus`

work on intervals,
too.

As of version 2.5, MuPAD implements the following operations
on elements of type `DOM_INTERVAL`

:

The trigonometric functions and their inverses:

`sin`

,`cos`

,`tan`

,`sec`

,`csc`

,`cot`

,`arcsin`

,`arccos`

,`arctan`

,`arccsc`

,`arccot`

.The exponential function and the logarithm.

The hyperbolic functions and their inverses:

`sinh`

,`cosh`

,`tanh`

,`sech`

,`csch`

,`coth`

,`arcsinh`

,`arccosh`

,`arctanh`

,`arccsch`

,`arccoth`

.The functions

`Re`

,`Im`

(real- and imaginary part),`abs`

,`sign`

and`arg`

(the `argument' = polar angle of a complex number).

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.

The output of an interval depends on the environment variable `DIGITS`

as
well as on the preference settings `Pref::floatFormat`

and `Pref::trailingZeroes`

.

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)

With the operator

`...`

(which in turn calls`hull`

):1 ... 4+I

The function

`interval`

creates elements of type`DOM_INTERVAL`

as well, but may return expressions:interval(x^2+sin(1))

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:

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).

Was this topic helpful?