`9↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑9` seems like a reasonable guess (barring encoding cheats/trickery like @masfuerte commented!)

Edit: I've misread the above comment and my number is is 64 bytes (significantly more than 64 bits. The largest 64 bit number through my approach would be `9↑↑↑↑↑↑9`, which is significantly smaller.

I can do you one better and specify that the normal base-2 integer represented by the bits is the number of up-arrows. But as /u/tromp has already pointed out, that is not very interesting.

Is there any intuition on how big this number is?

In terms of the Fast Growing Hierarchy, it's about f_62(9) or what the article would denote as [62] 9. It's way smaller than Graham's Number, which involves 64 iterations of mapping n to 3 ↑↑↑... {n uparrows) 3, whereas this expression has between 1 and 2 iterations.

If every atom in the universe had a universe inside each proton, there still wouldn’t be enough atoms within all the universes in the protons. In fact you might not make it to four arrows with the above lol

No, because it never sees its back!

By the astronomical definition of the word "orbit", no. Earth does circle Mercury though (and Mercury circles Earth).

In terms of this post - I suppose technically Earth does NOT circle the Moon, because we never see its back!

Now I had to imagine Mercury's motion in Earth's reference system, and that was painful.

Fun to see you here - I discovered this game through your videos! I think despite the lack of raw "content", I got a LOT of playtime out of this game by trying to push higher on the leaderboards.

Awesome!

I've considered trying to do some hyper optimisation, taking into account the number of cycles each instruction takes - it seems that a lot of people are interested in that.

That's not my natural style though. I've had plenty of criticism for not being performance sensitive, but that's not really how I unwind (although I do plenty of optimisation at work!).

It could be fun to explore ingame though.

Sarcasm noted. An apple would actually be more difficult to hit because of its reduced size.

Everyone is underestimating how hard it is to willingly kill a person. Shooting a paper target or apple at a range is nothing like sighting on a person, letting out your breath and pulling a trigger.

I did not talk about killing a person at all. I talked about shooting a target. It is sad in this case that the shooter's target was a person.

I would never want to try to see how difficult it would be, as you mention.

I think it's more appropriate to say TOTP /is (nearly)/ phishing-proof if you use a password manager integrated with the browser (not that it /doesn't need to be/ phishing-proof)

"Repeats" may be the term you're looking for. That would be interesting, however in some pieces it could make the overall document MUCH longer. It would be similar to loop unrolling.

I don't care if the document becomes longer. Finding repeat signs is driving me nuts :)

Why?

It can be hard during live performances, because it can incur large jumps in the sheet music which can be annoying to follow. Not a problem if you learned the pieces by heart or have a pageturner, but this is not always feasible or the case.

One reason is that repeats make it harder to use page-turner pedals.

From the article:

    My Lua data types have a notable difference from C Lua: an ability to be “frozen”.

The project has data about every location (doors, chests, etc.) and the conditions that must be met to allow access to those locations - for example [1]. From there the randomizer shuffles various entrances/exits and item locations around using rules that are mostly guaranteed to keep the game beatable.

[1] https://github.com/OoTRandomizer/OoT-Randomizer/blob/d1bb6c2...

Thanks! Somehow I missed it. Seems it's experimental.