A while back I read a paper about downsampling normal maps and converting lost detail into roughness

I can try to find it if you want

Fyi; you can scroll the code blocks if you zoom out until there is no more horizontal scroll on the page

Still sucky but at leas you can read the code

Can you remake the stacked graphs with the variable of interest at the bottom? Its hard to see the percentage of Rust when it's all the way at the top with a lot of noise on the lower layers

Edit: or make a non-stacked version?

Lots of valid criticism here of these graphs and the queries; I'll write a follow-up article.

You have a nice ternary counter going in the version numbers :)

Runs slow as hell on my phone. Around 10fps.

My phone is not great but drawing some circles and some text should not take 100ms. On any device.

Please tell me that, after noticing that the best interval length is 2, you simplified your implementation to something like this

    def perform_union_dnc(paths):
        if len(paths) == 0:
            return None
        if len(paths) == 1:
            return paths[0]
        middle = len(paths) // 2
        left = perform_union_dnc(paths[:middle])
        right = perform_union_dnc(paths[middle:])
        return perform_union_naive([left, right])

It's not exactly the same algorithm (top-down merging instead of bottom-up) but the performance should be very close.

Also, it can be optimized to avoid temporary lists if that turns out to be a win.

I didn't get to simplify the code further unfortunately. I could have, but I was running very tight on time with other things. In fact the running-in-production-version is even worse than what I've posted, I just went with what worked fast on the first try and moved on to something else immediately. But it can absolutely be improved further!

The figure in the title expressed in normal units

5.6 * 10^15 kilograms

Thanks, I didn’t notice the second million and wondered why a day’s supply of energy would be scientific news.

I think you meant to say 1.1 trillion elephants

2.24 billion olympic sized swimming pools

They wasted an opportunity to get a third thing meaning "million" into the same number with 5.6 x 10^6 million megagrams.

I came across this store the other day while browsing LinkedIn. It's actually by the same guy who made the EspoTek Labrador electronics board (disclaimer: I contributed to the Labrador repo back in 2019)

Yes, you can solve a cube by this simple algorithm

    i = 0
    while not solved
        apply move(i)

Interestingly, there is no constant function `move(i) = x` that makes this algorithm correct.

If there was, there would be a single element x of the rubik's cube group that generates the entire group (every element could be written as x^n)

This would imply that the group is commutative (x^n * x^m = x^(n+m) = x^(m+n) = x^m * x^n), which every cuber knows is false from experience (permuting moves does not lead to the same final configuration)

An interesting question would then be: whats the simplest piecewise-constant function that makes this algorithm work?

I.e. is it possible to use move x1 for the first n1 steps, then x2 for the second n2, then x3 for the next n3, ..., then xk for the next nk? And if so, what is the smallest k that makes it so?

The whole point is that in a way, there is that constant function that you say doesn't exist.

Or more specifically, there is a fixed sequence of moves that will traverse through every possible configuration of a Rubik's cube then take you back to whereveryou started. One of those states is the solved state. Meaning whenever you complete this sequence you will have done a full loop of all possible cube states.

The interesting thing is that it doesn't matter where you start, you can follow this same sequence. So you can be blindfolded, never see the cube, perform the sequence and one of those states will be a solved Rubik's cube.

That I believe is OPs point.

Yeah I got that, but it's really not as interesting as it seems. Let me explain why.

Say we have an array p[1], p[2], ..., p[n] with all possible rubiks cube configurations

Then this function will solve the cube:

    move(1) = p[1]^(-1)
    move(i) = p[i]^(-1) * p[i-1]

In laymans terms, the resulting algorithm is: assume the initial configuration is p[1], then solve it. If it wasn't, undo those moves then solve as if the initial position was p[2], etc...

So, yeah. Those fixed solving sequences / hamiltonian paths are actually very common. We can make one for any permutation of the group elements.

So I posed a more interesting question: what is the simplest sequence of moves that has this property?

This is also useful initializing empty circular linked lists

  node n = {
    .data = NULL,
    .prev = &n,
    .next = &n,
  };