Step 1 in this situatoon is to try and see if this is a known mathematically unsolved problem, and if it is, giving up.
Isn't this just trying to find a hamiltonian cycle, isn't this NP hard? That's when I would give up, especially because you put so many constraints in it to make it human walkable.
Edit: Of course you don't have to give up, but it's good to know what you get yourself into
Why would you give up just because something is NP hard if there are good algorithms to approximate a solution, and an approximate but good solution is useful?
Yeah, there are many problems which are np-hard in theory, but then realistic cases give you way more constraints that make them solvable. So many hard graph problems become way simpler when applied to real maps, because you know that if you start getting away from something, your minimum remaining distance grows. But on an abstract graph there's no real mapping to our dimensions.
There's no "information you wanted" in the plain np-hard version of traveling salesman for example. There's only cost. My point was that things get easier if you have the extra information and aren't solving the plain version anymore.
I remember asking myself this question years ago, and came to 162 bits. I was just a kid back then so the logic is probably wrong but I do wonder how simple the encoding could be under those constraints...
Edit: Here are the Notes
0 Empty
10 Pawn
1100 Knight
1101 Rook
1110 Bishop
1111 Queen
32 + 32 + 472
2 times 6 bits: position of the kings
30 bits: color mask
120 + 2*6 + 30 = 162 bits
We can store the rest using the methods from the blog post and add 18 bits for promotion, giving 180 bits.
I'm sure this isn't the most efficient way, and I think I had other methods and considered things like the bishops being able to occupy 32 squares, though special casing doesn't make sense because of promotions.
Technically if you got 8 bishops/queens/knights/rooks
You would occupy another 16 bits, giving 196 bits
I think the upper limit can be reduced at the cost of increasing the lower limit
EDIT2: I think I made the assumption at the time that to promote one piece you needed to capture at least one enemy pawn, giving the space for the two bits, which means the upper bound is actually 180 bits
Would love to see other people try in the comment section
Each pawn that wants to be promoted either takes:
(a) another 'special' piece (knight/rook/bishop/queen), in which case it has already bought enough bit budget to later be promoted; or
(b) another pawn, in which case this temporarily saves 1 bit (as the other pawn becomes a space), but then later we need 2 extra bits for the promotion, so we pay 1 bit extra per pawn in total
In the case of (b) there are now fewer pawns that can be promoted, and so worst case, we have to pay a budget of 1 bit per each of 8 promoted pawns.
So I think maximum required bits is only 162 + 8 = 170?
So for each 4 pawn cluster, 1 pawn takes another pawn, and the net result is +1 bit once the captor promotes. The remaining 2 pawns in the cluster each need 2 extra bits when promoted => 2 x 2 = 4 bits. So 5 bits per 4-pawn cluster, of which there are 4.
So maximum representation would be 162 + (5 * 4) = 182 bits?
Yep, that increase the total in 3*3-4=5 bits, and you can repeat it 4 times, so the maximum is at least 162+4*5=182.
I'm trying to prove that is the worst case, but there are just too many cases. I guess I'll try to use a program o brute force it or just forget about it.
Actually, given this, we believe that 4 pawns must have been captured to reach 182 bits. So at least 4 pieces no longer need colors. If we store the color mask at the end, I think we can make it variable length, and truncate when no further pieces need colors assigned.
So then we need maximum 182 - 4 = 178 bits
EDIT: Equivalently, we could suffix each non-empty piece in the sequence with an associated color bit
I thought the same but realized you can retrospectively 'insert' the king positions into the position sequence, shifting the remaining sequence one square along for each king, so no more bits required though the data structure is unwieldy!
I couldn't in good conscience work like that, I believe the risk of bad AI generated code due to the tiniest of output variation is far too high. Especially in systems that need to maintain a large state governed by many rules and edge cases.
I recommend having the AI do the typing while still reviewing, comprehensively testing and even dictating the exact shape of every line that you commit.
I remember another hacker news commentator describing these orbital data centers as a obviously bad idea to the point where any investments into that technology are incomprehensible. I share that sentiment, is there something I'm missing?
The point is to take the money, you see. It's the idiots who give it (which will involve looting the federal government for years to come) who will be screwed, not the guys running the scam. This should be evident after AI now. The entire industry is a narrative manufacturing machine aimed at separating investors from their money. That's all there is to it.
Some investments seem to be specifically crafted to attract people who do not understand X, where X is physics, or economics, biology, math, etc. And then giving in to greed and gambling is more fun than consulting an expert.
I wonder how many of these apparent start-up scams turned out to have genuine value.
As long as contributions happen in good faith and not just for the sake of contributing, but I'm assuming there's already a system in place to ensure that for other civic services.
There are two ways in which that could happen. Someone entered that combination into the list without thinking it though. Or more likely, they use a self-learning or heuristic filter that finds the combination 'Linux' and 'Apple M1' unusual because of how rare it is. Either way, it's easier to assume a mistake here because such a dark pattern doesn't make any business sense - notwithstanding their ethical reputation.
This is just a guess, but maybe "inconsistent" identifiers are a good signal of being an attack bot instead of a user.
Not defending that btw. Auto-generated signals are likely a problem for any desktop Linux user, not just Asahi, since most bots will run on Linux VPSs.
Isn't this just trying to find a hamiltonian cycle, isn't this NP hard? That's when I would give up, especially because you put so many constraints in it to make it human walkable.
Edit: Of course you don't have to give up, but it's good to know what you get yourself into
reply