We saw that the Maple environment allows for computation with integer and rational numbers, but it does not do so well with real numbers. We will see that Maple understands that $\sqrt{2}$ and $\pi$ are non-rational real numbers, but in general, it is quite difficult to do computations with them.
If we want to perform real computations, in general, we cannot, but we can approximate real computations with floating-point computations. With floating-point computations, each operand is evaluated to a fixed number of digits, the operation is then performed, and the result is then truncated to the given number of digits.
By default, the number of digits is ten (10).
> 1.234567890*2.345678901;
$2.895899851$
The exact solution is $2.89589985142508889$, but this is rounded to ten significant digits.
You may recall, or if you may not already be aware, that double-precision floating-point numbers (double) use 53 significant bits, which is approximately 16 decimal digits of precision, while single-precision floating-point numbers (float) uses less than eight. In Maple, you can prescribe the number of digits to which all floating-point computations are to be performed by assigning to the environment variable Digits:
[> Digits; # Print the value assigned to 'Digits'
$10$
This shows the default value of Digits, but we can assign to this environment variable, too:
[> Digits := 20;
$Digits := 20$
As soon as we do this, all floating-point operations use 20 significant digits:
> 1.2345678901234567890*2.3456789012345678901;
$2.8958998520042688603$
If you were to calculate the given product to all possible digits, then the actual value would be $2.8958998520042688603139767765142508889$, but this result is rounded to twenty digits.
It is important to realize that at all times, every operand is first rounded to a Digits-digit number, and only then is the calculation performed. For example, consider the following sum:
> Digits := 10;
$Digits := 10$
> 1.0000000005 + 1.0000000004;
$2.000000000$
Ideally, one would suggest that this should equal $2.000000001$; however, each operand is first rounded to two significant digits first, so we are really just calculating $1 + 1 = 2$.
Every floating-point computation is associated with an error. Indeed, every floating-point number represents a range of possible real nubmers. For example, 2.345678901 could represent any real number on the interval $(2.3456789005, 2.3456789015)$, so any real number on this interval could be represented by 2.345678901 when rounded to ten (10) digits.
We will right now introduce a new function: one that converts a an integer, a rational number into a floating-point number at the given number of digits:
> evalf( 22/7 );
$3.142857143$
> evalf( 355/113 );
$3.141592920$
> Digits := 20;
$Digits := 20$
> evalf( 355/113 );
$3.1415929203539823009$
> Digits := 113;
$Digits := 113$
> evalf( 355/113 );
$3.14159292035398230088495575221238938053097345132743362831$ $85840707964601769911504424778761061946902654867256637168$
It is no coincidence that 113 digits are required before you detect the first repeating decimal: why? (Hint: you'll notice there are 112 repeating decimals.)
$\frac{355}{113} = 3.\overline{14159292035398230088495575221238938053097345132743362831}$ $\overline{85840707964601769911504424778761061946902654867256637168}$
Incidently, $\pi = 3.1415926536\mdots$, so as an approximation $\pi$, $\frac{355}{113}$ has a relative error of 0.0000085%, or one part in twelve million.