SetPrecision and setting precision with a backtick

Question

When you use SetPrecision to set the precision of say 1.1 you will get some seemingly random numbers padded before the rest will be padded by zeros. I assume this comes from the true machine precision representation of 1.1 having these hidden numbers.

When you use backticks you do get the more intuitive result of the expression only being padded with zeros. This seems more desirable to me since what I want is to input floats as close to exact as possible (i.e. I mean that I want 1.1 to be as close as possible to 11/10 etc.)

But how do I use the backtick as a function. The Fullform is just the backtick and gives no hints for how to use it in a function. Naive tries such as #`40& are not considered valid syntax.

I guess a function could be constructed by multiplying by some power of ten and then rounding to an exact number. Followed by dividing by the same power of ten and using N[#, prec]& on the result but this seems needlessly complicated.

(Alternatively, explain to me why trying to get the backtick result is a bad idea.)

Answer 1

SetPrecision[1.1, 30]

gives

1.10000000000000008881784197001

but

SetPrecision[Rationalize[1.1], 30]

gives

1.10000000000000000000000000000

So perhaps using Rationalize will work for you.

Answer 2

One good solution is

N[FromDigits[RealDigits[#]],prec]&

In the test cases I tried it will exactly match the backtick input.

---

Alternatively, one other approach is to build the backtick expression as a string and then convert it to an expression (thus avoiding that before we assign a value the syntax is invalid):

toHighPrecision[x_, prec_] := ToExpression[ StringSplit[ToString[x, InputForm], "`"][[1]] <> "`" <> ToString[prec]]

This also works as expected, see:

toHighPrecision[#, 50] & /@ {1.1, 1.10000006, 
  1.10000000000000000000000008, 1.10000000000000000000000007}

(We had to split the string because the InputForm might contain a backtick already because MMA interprets it to have a certain amount of precision.)

---

My initial attempt for this strategy,failed because, even if I held the x, I still could not avoid some conversion from being made. For example,

SetAttributes[toHighPrecision,HoldAll];
toHighPrecision[x_]:=ToExpression[StringTake[ToString[Hold[x]],{6,-2}]<>"`"<>ToString[prec]]

did not work for 1.10000000000000008. The solution was proposed by LLlAMnYP, I should have used ToString[#,Inputform] instead.

---

Lastly, you can first convert the Real to an Integer. If we do this with Rationalize as proposed by m_goldberg we get a nice looking result, but this comes at the disadvantage of some loss of accuracy. (Our previous test case will be wrongly converted to 11/10).

---

To compare try:

N[FromDigits[RealDigits[#]],50]&[1.10000000000000008]
N[Rationalize[#],50]&[1.10000000000000008]
ToExpression[StringTake[ToString[Hold[#]],{6,-2}]<>"`"<>ToString[50]]&[1.10000000000000008]
ToExpression[StringSplit[ToString[#, InputForm], "`"][[1]] <> "`" <> ToString[50]]

Why the RealDigits solution works and does not run into the problem of a conversion is not 100% clear to me.

Answer 3

@LLlAMnYP, the goal is to enter numbers with a certain precision prec. The only problem is that entering all numbers in the format as required by Mathematica is really cumbersome. I want it to be assumed that all digits that are not given are exactly 0's. If I input 1.1 in the function I mean 1.1`prec. I don't know exactly what you mean, but if a "decimal number library" is a way to accomplish this then please expand on this. It also already seems that the function in my answer accomplishes exactly what I want (even though I don't exactly understand why). So practically I'm satisfied.

A proper response to this goes out of hand for a comment, so I'll expand here.

I want it to be assumed that all digits that are not given are exactly 0's.

This is sort of a definition for decimal arithmetic. You want numbers to be what they look like to you, and not to a computer.

1.1`prec, by the way, does not achieve that goal:

SetPrecision[1.1`5, 70]
1.100000000000000000000000000000000000001175494350822287507968736537222

Though it does give you a bunch more zeroes before imprecise digits show up. So, I conclude, the numbers are still stored in binary form. The output from using the backtick is simply tricking you into believing, that the number is truly an exact 1.1 because it is using more binary digits of precision.

You also state "Fullform is just the backtick and gives no hints for how to use it in a function". Let me try to draw a parallel with C/C++ where you can input numbers in several ways, e.g.

0x0ab13  // hexadecimal
0777     // octal
15805687280289L // long

but, of course, one cannot simply write

int toOctal(int n) {
  return 0n;
}

There is low-level code in the compiler that interprets the strings making up a program in a certain way, like interpreting the string as an octal number if it sees 0 after a whitespace and backticks in Mathematica serve a similar function. However, every function you use always has an intermediate step of converting the inputted decimal number to a binary number. Usually, the shortest sufficiently exact representation of that number does not show the trailing non-zero digits, so all looks well. But your end-goal is not clear to me, so I cannot advise you on how to proceed and whether you will eventually run into problems.

However, since we live with the decimal system and often count money as a fixed-point decimal number, we recognized the need to carry out exact calculations with decimal numbers, so just like there exist bignum libraries that can work with numbers much bigger than 64 bits, so there exist decimal libraries that store numbers as a decimal representation, not as the closest base-2 equivalent. Mathematica appears to have such a library. Please refer to the ComputerArithmetic package.

<<ComputerArithmetic`