# What is the meaning after a number with a  symbol? [duplicate]

Sometimes, when copy pasting some output obtained in Mathematica I obtained a weird comma after a number and then more numbers. Imagine, and output for a computation is

0.4244131815783875620503567023 m


where m is a variable. Then I copy paste this output and I obtain

0.4244131815783875620503567023267049654227.98876486962581 m


Playing with expressions like this I think the 27 in 27.98876486962581 just means that the number before has 27 precision. But What does the 98876486962581 mean? What is the meaning of this seemingly weird number after the upward comma?

• This means that the number 0.4244131815783875620503567023267049654227.98876486962581 has 27.98876486962581 digits of precision. If there is no number after the backtick like in "0.4244131815783876", then it means that the number is in machine precision. Sep 27, 2018 at 9:09
• Have a look at \$NumberMarks. Sep 27, 2018 at 9:11
• @HenrikSchumacher what is the meaning of 27.98876486962581 digits of precision ?! they surely this should be an integer number (unless you have analytically extended the function in the complex digits of precision plane ( this is a joke)) Sep 27, 2018 at 9:14
• Well, that is one of the mysteries of the arbitrary floating point precision capabilities in Mathematica ;) Anyways, it has to do with the fact that floating point numbers are not stored in the "conventional way as lists of digits (see also fixed-point arithmetic) but as mantissa and exponent... Sep 27, 2018 at 9:20

This means that the number

0.4244131815783875620503567023267049654227.98876486962581


has 27.98876486962581 digits of precision. If there is no number after the backtick like in

0.4244131815783876


then it means that the number is in machine precision.

That non-integer numbers of "digits" may occur has to do with the way how floating point numbers are stored: In contrast to fixed point numbers which are stored as mere lists of binary digits, floating point numbers are stored by mantissa and exponent.

Moreover, Mathematica's arbitrary precision arithmetic tries to track the uncertainty of a number by actually treating finite precision numbers as intervals. The number of digits of a "number" $$x \pm \delta/2$$ is then computed as the (negative) logarithm of the width of this interval relative to its magnitude. More precisely, as can be read in the documentation cited by J.M.:

$$\mathrm{Precision}[x] = - \log_{10}(\delta / |x|).$$

If I am not mistaken, computations in arbitrary precision have to use interval arithmetic or at least have to provide upper bounds good approximations for the radius of uncertainty in order to keep track of the interval boundaries.

This is a feature that computations in machine precision actually do not have.

Often, one says that a machine precision number "has about 16 significant digits" or it has "16 digits of precision". But "counting the digits" of a number does not tell you how many of these digits you may trust. Mathematica uses a much stronger notion of precision: If the arbitrary precision number x is a result of a computation then its Precision provides an upper bound estimator of an upper bound of its relative error:

$$|x - x_{\mathrm{true}}| \leq |x| \, 10^{-p} \quad \text{with p \approx \mathrm{Precision}[x]}.$$

A priorily, a result in machine precision can have arbitrarily high relative error, hence arbitrarily low precision in this stronger sense of precision. This is why Precision returns MachinePrecision of machine precision numbers: It just cannot tell how exact they are.

# Edit:

As Daniel Lichtblau pointed out in a comment (and probably diluted by my interpretation), Mathematica estimates the error propagation of $$x \pm \delta$$ under the operation $$x \mapsto f(x)$$ essentially by

$$f(x \pm \delta) \approx f(x) \pm |f'(x)| \, \delta$$

or by something similar. If $$f'$$ is Lipschitz continuous with Lipschitz constant $$\varLambda \geq 0$$, the true uncertainty can be bounded by virtue of Taylor's theorem as follows:

$$|f(x) - f(x \pm \delta)| \leq |f'(x)| \, \delta + C_f \, \delta^2.$$

So, if the uncertainty $$\delta$$ is small in the beginning and if $$C_f$$ is not astronomously large, then $$|f'(x)| \delta$$ is very good estimator for $$|f'(x)| \, \delta + C_f \, \delta^2$$, the "true" upper bound of uncertainty.

Of course, problems arise if $$f$$ is not differentiable everywhere or if $$f'$$ does not have a global Lipschitz constant. This happens for example for the infamous function $$f(x) = \frac{1}{x}$$. However, that's nothing new: Division by small numbers has to be done carefully.

• Computations in arbitrary (but finite) precision use significance arithmetic. The error estimates come from derivatives (they are first order bounds) and are not guaranteed to be upper bounds due to effects from higher order derivatives. For basic arithmetic (plus/times/reciprocal) one can show they do a very good job though. Sep 27, 2018 at 13:35
• Many thanks for the clarification, @Daniel. I tried to correct my speculations to the best of my knowledge. Please correct me if I am mistaken. Sep 27, 2018 at 14:45
• Might want to also mention RealExponent, Accuracy and their relationshipt to Precision as well as the input form 1232 Sep 27, 2018 at 14:53