Any progress, xeda?

Other people: come on guys, it's great fun to try it

With the fancy trick, the loop that checks the products is the slowest part (benchmarking shows that part to take about 10 times as long as the loop that checks the sums), though I can't prove this bound, I would theorize that makes it O(n^1.5) (obviously without the trick, checking the sums takes much longer since there are far more of them). I'll look into how (if at all) that could be improved.

Probably undecidable in general, if in "any" is included the control flow operators and so on, there would be a huge class of programs that might output the number you want but you don't know if they even halt.

By the way here are a couple of test cases (you probably won't get the same answer of course)
1337 = 7379**2+* (9 characters)
9001 = 55589****1+ (11 characters)
12345 = 364888***9+*+ (13 characters)
987654 = 8885688***9+***6+ (17 characters)
9876532 = 2258885688***9+***5+**+ (23 characters)
9876543 = 789**4+56899****2+*7+ (21 characters)
53887677 = 365688**7+7899**7+*9+**9+*+ (27 characters) (lowest number that requires 27 characters)
98765432 = 489*2+6927779****5+**1+** (25 characters)

You've probably heard that a map (with some restrictions: no enclaves, no "bridges", countries meeting at a point are not considered adjacent) can be colored using only four colors.

Graph coloring is a bit more general: given a bunch of "nodes" with "edges" between them, color the nodes such that no two adjacent (ie, have an edge between them) nodes have the same color. A trivial way to do that would be giving every node its own color. A bit better would be to start at the first node, give it color 0, then the second node can have color 0 or 1 (depending on whether it's connected to the first) and so on, and there are tricks you can play here with the order in which you visit the nodes (it matters a lot, and in fact there is an order such that you get an optimal coloring this way, there are many interesting things you can do there).

The challenge is usually to find such a coloring with the fewest possible number of colors, but you could also ask: given a certain number of colors you're allowed to use, can you color the graph? (this is an example of an NP-complete problem)

Anyway for this mini challenge, there are two graphs (I could make more, if necessary), a small one with 50 nodes and 350 edges, and a big one with 500 nodes and 62423 edges. The second one is particularly nasty not so much because it has 500 nodes, but mainly because it has about half as many edges as it could maximally have, which is about the worst case (more edges and it becomes so constrained that there are not many solutions to try, less edges and you won't need as many colours so again there are few solution). But whatever, the point is, there's an easy one and a hard one. The east one is still big enough that you can't blindly try everything though, you have to be at least slightly clever.

50 graph: gc50.txt
500 graph: gc500.txt
Format: first line is [number of nodes] [number of edges]
Other lines are the edges, a pair of nodes that has a link between them.
The last line is empty (so that every line you read can end in \r\n to simplify parsing or whatever), and there are exactly as many edges as advertised (so you can read them in a for loop and not care about end of file).

Challenges (easy):

• Find an optimal coloring for gc50.
• Find a coloring with at most 80 colors for gc500.
• Prove that you need at least 11 colors to color gc500.

Challenges (medium):

• Find a coloring with at most 60 colors for gc500.

Challenges (hard):

• Find a coloring with at most 52 (protip: that's not optimal) colors for gc500.

Challenges (impossible):

• Find an optimal coloring for gc500. (I don't even know how many colors it will have, so don't ask)

Challenges (other):

• Find a non-trivial lower bound on the number of colors necessary for gc500 (deliver proof/explanation of why it's a lower bound).

PM answers to me (don't post colorings please, feel free to post lower bounds), discuss everything (as long as it doesn't violate "don't post colorings"), pretty much anything goes with respect to how you solve this but it will be more interesting for you if you play with the problems yourself instead of just dumping them into open source solvers.

Is it the orientation though? In my test, also moving the level made a difference. Perhaps it's the relative position of the level with repeaters?

A repeater is itself a block, so it adds a delay of 1 tick minimum.

That can't be the whole story though. Both repeaters have a delay of 1 tick, so both would turn on at the same moment (1 tick after the signal turns on). However, in the case with just the 2 repeaters, the one that locks the other (let's call it A, and the one that is locked B) consistently turns on first.
Then if you add a third repeater C that can be locked by repeater B, and then power is supplied to all three simultaneously, obviously A always turns on since nothing prevents it from doing that, so it locks B, but then B either locks C or doesn't lock C, depending on whether or not B was locked in its ON state (which one wins depends on where power flows from). So now the entire situation is changed, even though all that happened is that we gave repeater B the chance to lock something.

Oh, I thought it was your implementation... The reason could be that minecraft does it the way I mentioned: Random ticks per chunk, but it has to tick every block in a chunk first before it ticks a block the second time (I'm not sure how to explain it better). What happens if you connect two not gates to the repeater inputs (input & lock) instead of a repeater? Does the behaviour change if you change orientation, location etc.?

Could you draw the circuit?

With statefulness my old Minecraft clone (years ago, lwjgl) achieved a 2-calls-per-chunk renderer (IIRC. It was an experiment how to get most performance out of LWJGL with a lot of cubes and big worlds)

Well how? glBindVertexArray, glDrawElements .. nothing left to change state. I'd have 2 calls if it wasn't for the uniform buffer.