How is your progress? Are you feeling now more confident? 3 years have passed

definitely harder than 8 kyu

But the descripition doesn't say to do what you are doing anywhere. Nowhere in the description does it say to compare two different bits, as you are doing, you do not need to compare two different bits. In other words, you do not need knowledge of the previous or next bit in order to encode the next pit/land.

Again the key is "a change from pit to land or land to pit indicates a one, while no change indicates a zero"

So bit 1 = L (if the previous indent was P) or P (if the previous indent was L) and bit 0 = L (if the previous indent was L) or P (if the previous indent was P)

As per the description: "a change from pit to land or land to pit indicates a one, while no change indicates a zero"

So in the example, "PL" encodes 1, "LL" encodes 0, "LP" encodes 1. "PP" encodes 0.

how long did it take you to get to 4th Kyu?

Rather than searching for how to make naïve approaches faster, try thinking about mathematical properties that can be inferred when you only need the last digit.

Just tried numba at home:

Traceback (most recent call last):
...
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
non-precise type pyobject
During: typing of argument at <input> (5)
File "<input>", line 5:
<source missing, REPL/exec in use?> 
This error may have been caused by the following argument(s):
- argument 0: Int value is too large: 11589622874141843207737526893160045027229209055888190994639
- argument 1: Int value is too large: 10185873300040714483538003999669899935043458641404648017

I doubt you can find any library able to compute efficiently, for example, 11589622874141843207737526893160045027229209055888190994639 ** 10185873300040714483538003999669899935043458641404648017101.

I had this problem when my solution relied on modifying the function parameters (even though other test cases were fine). The solution was to not do this!

Try reading up on "side effect".

you were right to point it out, it has now been fixed ^w^

Hm, ok, I saw the corrected version so I misunderstood elevenpix' message.

no he is right, the bracket was incorrect in the cipher example. i fixed it (sorry about the merge conflict, but it was already there anyway because my Python fork got approved)