# A probable misdescription of official Doc about $MachinePrecision? According to the official documentation: When you enter an approximate real number, the Wolfram Language has to decide whether to treat it as a machine number or an arbitrary‐precision number. Unless you specify otherwise, if you give less than $MachinePrecision digits, the Wolfram Language will treat the number as machine precision, and if you give more digits, it will treat the number as arbitrary precision.

However the code below disagree:

In[237]:= $MachinePrecision Precision[0.1000000000000000](*16 digits*) Precision[0.10000000000000000] (*17 digits*) Precision[0.100000000000000000](*18 digits*) Out[237]= 15.9546 Out[238]= MachinePrecision Out[239]= MachinePrecision Out[240]= 17.  It's only up to 18 digits that it is recognized as an arbitrary precision number. Is the documentation wrong? Also, why Precision[0.100000000000000000](*18 digits*) output 17? I think it should be 18. ## update 2020-06-07 I sent an email and has received the reply from Wolfram Official. It has been confirmed this is an documentation mistake: Hello, Thank you for contacting Wolfram Technical Support. I understand that the statement about precision in the following tutorial: https://reference.wolfram.com/language/tutorial/InputSyntax.html#19291 contradicts the statement about precision in the Numerical Precision section of the following tutorial: https://reference.wolfram.com/language/tutorial/Numbers I will file a report with our developers regarding this issue. Thank you for bring this to our attention. Regards, Luke Titus Wolfram Technical Support Wolfram Research Inc. http://support.wolfram.com • But notice that the precision of your 18-digit number is only 17, as you show, and indeed this is the first one that is treated as arbitrary precision because it is the first to have more than $MachinePrecision digits of precision. So the documentation is accurate there. Why, then, the number with 18 apparent decimal digits only properly has 17 digits of precision is your real question, and I suspect that this has to do with number representation, something I wish I had a better grasp of. – MarcoB May 17 at 16:28
• @MarcoB About "So the documentation is accurate there". Documentation said "give less than \$MachinePrecision digits" not "give a number with precision less than \$MachinePrecision", so it's inaccurate. – Murphy Ng May 17 at 16:33
• Consider Accuracy[0.100000000000000000] (18 digits). Note "treat the number as arbitrary precision" makes no promise about the Precision of the number. – Michael E2 May 17 at 16:58
• @Murphy What are you looking for here? If your only intent is to point out an imprecision in the docs, then you need to contact Wolfram Support. Otherwise, I think you will be interested in the specific definitions of Precision and Accuracy, as reported in the respective documentation pages. I find those concepts pretty hard to keep straight myself, but I think you might be switching up Accuracy and Precision. – MarcoB May 17 at 17:55
• @MarcoB My intent is to point out an imprecision in the docs and, what's more important, find the precise rule behind Mathematica. – Murphy Ng May 17 at 18:14

An approximate number x is taken to be machine precision if the number of digits given in it is Ceiling[$MachinePrecision]+1 or less. If more digits are given, then x is taken to be an arbitrary‐precision number. The accuracy of x is taken to be the number of digits that appear to the right of the decimal point, while its precision is taken to be Log[10,Abs[x]]+Accuracy[x]. For a possible explanation why Ceiling[$MachinePrecision]+1 is chosen, see the SO Q&A Why do I need 17 significant digits (and not 16) to represent a double?
If Accuracy[0.100000000000000000] is 18., then Precision[0.100000000000000000] should be Accuracy[0.100000000000000000] + Log10[0.100000000000000000], which is 17.
Frankly, one ought to avoid relying on the "convenience" of writing a long sequence of digits to set a precision/accuracy to what you want. Use the back-tick input form, SetPrecision or SetAccuracy instead. Sometimes the convenience might outweigh the potential for mistakes. The number might come from an external data source in such a form, for instance, but one should probably check and set the accuracy by hand since the rule above might not be how the accuracy of the data should be treated.