Weird Calculator

The following sequence of $\boxed{41}$ button presses will produce $3.14159265$ on Lynn's calculator:

$\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{\div 2}$ , $\boxed{+1}$ , $\boxed{+1}$ , $\boxed{+1}$

The binary representation $11.0010010000111111011010101$ is sufficient to find $\pi$ to $8$ decimal places. The most efficient way to represent the numbers after the decimal on Lynn's calculator is to read from right to left and use $\boxed{+1}$ , $\boxed{\div 2}$ for each $1$ and $\boxed{\div 2}$ for each $0$ . Since there are $13$ $1$ s after the decimal at $2$ button presses each, and $12$ $0$ s after the decimal at $1$ button press each, there are $13 \cdot 2 + 12 \cdot 1 = 38$ total button presses to obtain the correct numbers after the decimal ( $0.14159265$ ). Then an additional $3$ $\boxed{+1}$ buttons are necessary to add $3$ more to obtain the correct answer of $3.14159265$ , for a total of $38 + 3 = \boxed{41}$ button presses.

The two available functions on the calculator have simple effects when applied to binary numbers: the $\boxed{+1}$ function adds $1$ to the number before the point, and the $\boxed{\div 2}$ moves all the bits one to the right. For example, $0.101+1=1.101$ and $1.101 \div 2 = 0.1101$ .

This means it is possible to produce such a number by considering the bits from the right end, pressing the $\boxed{+1}$ button to produce a $1$ , then pressing the $\boxed{\div 2}$ button to continue progressing along the bits towards the left. We can now calculate the total number of button presses to make such a number:

• Every individual bit after the point requires one press of the $\boxed{\div 2}$ button
• Every $1$ after the point requires one press of the $\boxed{+1}$ button
• The number before the point requires pressing the $\boxed{+1}$ button enough times to count up to the desired number

The binary number $11.0010010000111111011010101$ is the shortest number that will display $\pi$ to $8$ decimal places.

There are $25$ bits after the point, $13$ individual $1$ 's after the point, and $3\ \boxed{+1}$ presses needed to count to the $11$ before the point, meaning a total of $25+13+3=\boxed{41}$ button presses are required to produce the number.

Edit: To determine the shortest possible binary number, I used a brute force approach, taking a number known to produce $\pi$ to $8$ decimal places and then rounding it down/up to the next smallest bit until any further changes would no longer produce the correct decimal solution. In this case, $11.0...101$ can be rounded either down to $11.0...1(00)$ or up to $11.0...11(0)$ , but these both produce $\pi$ accurate to only $7$ decimal places.

Only the bits between $2^1$ and $2^{-25}$ are necessary to get the needed precision. Starting from the last bit and working backwards, one needs $13$ presses of the $+1$ key, because that’s how many $1$ ’s there are in the binary presentation of $\pi$ with the desired accuracy, and $25$ presses of $\div2$ , to get to $0.14159265160561\dots$ . Adding 1 three more times to get to $\pi$ makes the answer $25+13+3=41$ .

A truncated binary representation of $\pi$ to the $n$ th corresponds to a sequence of $+1$ and $\div 2$ in the following way:

$\begin{aligned} 11.001001 \text{ (in binary)} &= 2^1\cdot 1 + 2^0\cdot 1 + 2^{-1}\cdot 0 + 2^{-2}\cdot 0 + 2^{-3}\cdot 1 + 2^{-4}\cdot 0 + 2^{-5}\cdot 0 + 2^{-6}\cdot 1 \text{ (in decimal)}\\ &= 1 + 1 + 1 + \frac{1}{2} \left( 0 + \frac{1}{2} \left( 0 + \frac{1}{2} \left( 1 + \frac{1}{2} \left( 0 + \frac{1}{2} \left( 0 + \frac{1}{2} (1 + 0) \right) \right) \right) \right)\right)\\ &= ((((((((((((0)+1)\div 2)\div 2)\div 2)+1)\div 2)\div 2)\div 2)+1)+1)+1 \end{aligned}$

Using a program, we can iterate through the $i$ th truncation of $\pi$ in binary, evaluate the corresponding decimal expression rounded to the eighth decimal, until we find one that matches $3.14159265$ . An example of a program written in Elm is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

piBinary =
    "11.00100100001111110110101010001000100001011010001100001000110100"

answer = List.range 0 (String.length piBinary)
        |> List.map
            (flip String.left
                (String.dropLeft 3 piBinary)
                >> String.foldr
                    (\c ( x, n ) ->
                        if c == '1' then
                            ( (x + 1) / 2, n + 2 )
                        else
                            ( x / 2, n + 1 )
                    )
                    ( 0, 0 )
                >> (\( x, n ) -> ( x + 3, n + 3 ))
            )
        |> List.filter
            (Tuple.first
                >> roundTo 8
                >> (==) 3.14159265
            )
        |> List.head
        |> Maybe.map Tuple.second

roundTo decPlace n =
    toFloat (round (n * 10 ^ decPlace)) / 10 ^ decPlace

Needing ceiling log(10**9,2) binary digits to hold 8+1 decimal digits, the gross number of binary digits comes to ~29.9 (or 30 whole digits).

In the string the first 30 binary digits are .....10101000 (note the three trailing zeroes). The position of the rightmost 1 binary digit is at 25 fractional binary digits (30 - 2 (whole digits) - 3 (trailing zeros)). Since the next three (rightmost) are zeros, they do not need to be included in the button operations.

Counting the number of 1s in the fractional portion to be 13. The fractional binary 1s map to a +1 operation. Their position and each zero position all represent a division by 2 operation.

So we are at 13 + 25 operations for the fractional part.

For the whole portion, three +1s are needed (without any further divisions).

So total sum in this case are 13+25+3 = 41

C#/LINQ

// one-liner
Enumerable.Range(1,62).Select(n=>"00100100001111110110101010001000100001011010001100001000110100".Take(n).Reverse().Select(b=>b-'0').Aggregate((c:3,a:0.0),(s, b)=>(c:s.c+b+1,a:(s.a+b)/2))).Where(s=>s.a>0.14159265).Select(s=>s.c).First()

41

// to expand
Enumerable.Range(1,62)     // for n = 1 to 62
.Select(n =>    
    "00100100001111110110101010001000100001011010001100001000110100"  // pi minus 3
    .Take(n)   // take first n bits 
    .Reverse()   // smallest bits first
    .Select(bit => bit-'0')   // turn char into 0/1
    .Aggregate(    // run through all bits
        (clicks:3, acc:0.0), // calculator accumulator initially 0; 3 clicks represent the final 3 [+1] for integer part of pi
        (state, bit) => (clicks:state.clicks+bit+1, acc:(state.acc+bit)/2)    // if bit = 1 [+1][/2] else [/2]   
    )         
)  // result is 62 (clicks,acc) pairs
.Where(state => state.acc > 0.14159265)  // filter those where acc is first 8 digits
.Select(state => state.clicks) // take #clicks
.First() // filter on first value - least as #clicks increases with n

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

digits = '00100100001111110110101010001000100001011010001100001000110100'
target = 0.14159265

for j in range(1,len(digits)):
    num = 0    
    taps = 0
    for i in digits[j::-1]:
        if i == '1':
            num = num + 1
            taps = taps + 1
        num = num / 2
        taps = taps + 1
    if int(num*100000000)/100000000 == target:
        print(taps + 3)
        break
else:
    print('More digits needed.')

I used round(num,8) == target first, so I got 42. I think this would be better, as calculators usually round the value instead of showing the first x digits. But I understood how the problem was meant, so got it for the second try.