Fellas, is it woke for YouTube to funnel viewers towards pro-fascist videos?

It's worth bumping the priority up. I'm usually not that big on slice of life, but Machikado Mazoku is great.

Don't give your coins to politicians, kids. They'll just become dependent and less able to survive in the wild.

Unfortunately:

However, her veto is only symbolic as the prime minister's Georgian Dream party has enough members in parliament to override it by holding another vote.

Personally, I’ve yet to see a single American successfully use guns to protect any other constitutional right from government infringement.

The Battle of Athens is probably the most uniquely clear-cut example of what you're asking for, unless we count the American Revolutionary War itself.

Other successful examples mostly involve activists using non-violent protest to push for change, while using firearms to protect themselves from violent reactionaries that would otherwise murder them. Notably, the civil rights movement of the 1950s and 60s. For a modern example, there's various "John Brown Gun Clubs" and other community defense organizations providing security at LGBTQ events against fascist groups that seek to terrorize event-goers.

It's also worth noting that resistance is often worthwhile even if it doesn't result in unqualified victory. For example, the Black Panthers' armed cop-watching activities saved a lot of Black folks from brutal beatings at the hands of the police, even if the organization was eventually crushed by the federal government.

I have seen lots of examples like Waco and Ruby Ridge, where the government should have tried harder to deescalate, but in the end, everyone died. The closest example I can think of where the government did backoff was the Bundy standoff and all those guys were “defending” was their ability to let their cattle graze illegally on federal land because they didn’t want to pay for access like everyone else.

It sounds like you might be in a bit of a filter-bubble. I don't mean any offense by this, it's a normal thing that tends to happen to people. If the news sources you read and the people you talk to don't mention these things because it doesn't mesh with their worldview, how would you hear about them?

Strong gun control requires a police state, and it's advocates are okay with this. Some of them (mostly suburbanites and the like) just imagine that that police state will never be directed against them.

Others are capitalists that actively want to inflict a police state on the rest of us, for their own benefit. It's a lot easier to break strikes and enforce "work discipline" when the working class is disarmed.

Food Courts Martial

I see conservatives complaining about it occasionally, but I'm not sure how prevalent that sentiment is among them.

How big is a Bitcoin transaction anyway?

Bitcoin block 841,308 (most recent as I'm writing this) is 1,615,771 bytes and has 3,148 transactions, for an average transaction size of ~513 bytes.

Because a Monero transaction is about one and a half to two kilobytes

So yeah, about 3 to 4 times as large as an average Bitcoin transaction.

Keep in mind we have dynamic block scaling so that the blocks will get larger as more transactions come in.

That's not a scaling solution, though. Larger blocks provide throughput at the expense of decentralization, since fewer people will run full nodes as resource usage increases. Eventually it gets to the point where it becomes feasible for a government to track down and compromise all the remaining node operators.

It seems like lightning service providers may very well be considered money transmitters

Not sure how much this would matter. Lightning wallets don't care whether their channel partners are registered money transmitters, or just some rando operating through TOR or in a permissive jurisdiction. In the case of Samourai, taking down the backend rendered the wallet useless. Taking out a lightning node just temporarily inconveniences users that were connected to them.

Monero may be a good option for some individual users right now, but it isn't a long-term solution for bringing financial privacy to the masses. That pretty much has to be done through Bitcoin wallets with privacy features. Bitcoin is already criticized for not scaling well, but Monero is far worse. If I remember correctly, Monero transactions are roughly 4 times as large as Bitcoin transactions, and they don't have any way to do off-chain transactions the way Bitcoin can with Lightning.

Yes, I agree.

Doesn't really have anything to do with the public ledger aspect. They got busted because they were maintaining a backend service that their wallet was dependent on, and they were making money from it. Simply releasing a wallet with privacy features is still presumably legal (IANAL) due to free speech protections applying to code. The government can still prosecute end-users directly, but the same is true for users of dedicated privacy coins.

Source is Tenchi Muyo! Ryo-Ohki, for you young'uns that don't recognize it.

Are there any physical obstructions between the controller and the antenna? That'd reduce the effective range.

Source is In/Spectre. 2channel propaganda starts around episode 9 or 10.

I think it's actually a pretty old term. Definitely useful for the internet era though, now that we end up coming into contact with many more "interesting" characters than in the old days. xD

Possibly. I've seen comments from them here and there in various places, but it's true that I haven't had the responsibility of moderating them like you have.

HardlightCereal seemed more like a crank than a troll, to me. Cranks are by definition at least somewhat annoying, and tend to get mistaken for and treated as trolls. They're not malicious the way trolls are though, and can be a positive influence. I think them drawing attention to this particular issue was a good thing, at least.

Tokyo Godfathers

Moderator here. While it's reasonable to post your anime podcast here once, making a post for each episode is an excessive amount of self-promotion, at least for the activity level that we've currently got here. I'll leave your existing posts up, but please refrain from making any more of them.

Found here

• Day 23, part 2 rewrite

Nim

Part 1 was just a simple search. Part 2 looked like it just needed a trivial modification, but with the removal of the one-way tiles, the result I was getting was getting for the example was too large. I switched to a different method of determining the path length, but didn't yet figure out what what I had been doing wrong. Since the search space was now significantly larger, my part 2 code took almost an hour to come up with the answer.

I rewrote part 2 to simplify the maze into a graph with a node for each intersection and for the start and goal tiles, with edge costs equal to the path length between each. This resulted in significantly faster iteration (17 seconds instead of 52 minutes), but didn't actually reduce the search space. I'm assuming there's some clever optimization that can be done here, but I'm not sure what it is.

The rewrite was still getting the wrong answer, though. I eventually figured out that it was including paths that didn't actually reach the goal, as long as they didn't revisit any nodes. I changed my recursive search function to return a large negative result at dead ends, which fixed the issue.

• Day 23, part 1
• Day 23, part 2

Nim

I sorted the bricks by their lower Z coordinate, then tried to move each of them downward, doing collision checks against all the others along the way. Once a level with collisions was found, I recorded each colliding brick as a supporter of the falling brick.

For part 1, I made another table of which other bricks each brick was supporting. Any bricks that weren't the sole support for any other bricks were counted as safe to disintegrate.

For part 2, I sorted the bricks again after applying gravity. For each brick, I included it in a set of bricks that would fall if it were removed, then checked the others further down the list to see if they had any non-falling supporters. Those that didn't would be added to the falling set.

Initially I was getting an answer for part 2 that was too high. I turned out that I was counting bricks that were on the ground as being unsupported, so some of them were getting included in the falling sets for their neighbors. Adding a z-level check fixed this.

Both of these have room for optimization, but non-debug builds run 0.5s and 1.0s respectively, so I didn't feel the need to write an octree implementation or anything.

• Day 22, part 1
• Day 22, part 2

Nim

My part 2 solution assumes the input has an unimpeded shortest path from the center of each garden section to its corner, and to the center of its neighbor. The possible destinations will form a diamond pattern, with "radius" equal to the number of steps. I broke down the possible section permutations:

• Sections that are completely within the interior of the diamond

  • Even number of sections away from the starting section
  • Odd number of sections away from the starting section

• Sections containing the points of the diamond

• Depending on the number of steps, there may be sections adjacent to the point sections, that have two corners outside of the diamond

• Edge sections. These will form a zig-zag pattern to cover the diamond boundary.

  • "Near" edge sections. These are the parts of the zig-zag nearer to the center of the diamond.
  • "Far" edge sections. These won't occur if the edge of the diamond passes perfectly through the corners of the near edge sections.

I determined how many of each of these should be present based on the number of steps, used my code from part 1 to get a destination count for each type, and then added them all up.

• Day 21, part 1
• Day 21, part 2

Nim

Another least common multiple problem. I kinda don't like these, as it's not practical to solve them purely with code that operates on arbitrary inputs.

• Day 20, part 1
• Day 20, part 2 partial solution
• Day 20, part 2 answer

Yeah, I laughed at that bit. Big "I am not a member of the National Socialist German Worker's Party" energy.

Nim

Part 1 was pretty straightforward. For part 2 I made an ItemRange type that's just one integer range for each attribute. I also made a split function that returns two ItemRange objects, one for the values that match the specified rule, and the others for the unmatched values. When iterating through the workflows, I start a new recursion branch to process any matching values, and continue stepping through with the unmatched values until none remain or they're accepted/rejected.

• Day 19, part 1
• Day 19, part 2

Yeah, I read up on ear clipping for a small game dev project a while back, though I don't remember if I actually ended up using it. So my solution is inspired by what I remember of that.

Yep, I figure it's good exercise to make me think through the problems thoroughly.

Shoelace formula

This would have been really useful to know about. I've committed to a certain level of wheel-reinvention for this event unless I get really stuck, but I'm sure it'll come up again in the future.

• Day 18, part 2

Nim

I am not making good time on these anymore.

For part 1, I walked through the dig plan instructions, keeping track of the highest and lowest x and y values reached, and used those to create a character grid, with an extra 1 tile border around it. Walked the instructions again to plot out the trench with #, flood-filled the exterior with O, and then counted the non-O tiles. Sort of similar to the pipe maze problem.

This approach wouldn't have been viable for part 2, due to the scale of the numbers involved. Instead I counted the number of left and right turns in the trench to determine whether it was being dug in a clockwise or counterclockwise direction, and assumed that there were no intersections. I then made a polygon that followed the outer edge of the trench. Wherever there was a run of 3 inward turns in a row, that meant there was a rectangular protrusion that could be chopped off of the main polygon. Repeatedly chopping these off eventually turns the polygon into a rectangle, so it's just a matter of adding up the area of each. This worked great for the example input.

Unfortunately when I ran it on the actual input, I ran out of sets of inward turns early, leaving an "inside out" polygon. I thought this meant that the input must have intersections in it that I would have to untwist somehow. To keep this short, after a long debugging process I figured out that I was introducing intersections during the chopping process. The chopped regions can have additional trench inside of them, which results in those parts ending up outside of the reduced polygon. I solved this by chopping off the narrowest protrusions first.

• Day 18, part 1

The rest of the code:

• Day 17, part 2 (24-48 hours)
• Day 17, part 2 rewrite (115ms)

Nim

Another tough one. Judging by the relative lack of comments here, I wasn't the only one that had trouble. For me this one was less frustrating and more interesting than day 12, though.

I solved part 1 by doing a recursive depth-first search, biasing towards a zigzag path directly to the goal in order to establish a baseline path cost. Path branches that got more expensive than the current best path terminated early. I also stored direction, speed, and heat loss data for each tile entered. Any path branch that entered a tile in the same direction and at the same (or greater) speed as a previous path was terminated, unless it had a lower temperature loss.

This ran pretty slowly, taking around an hour to finish. I took a break and just let it run. Once it completed, it had gotten pretty late, so I did a quick naive modification for part 2 to account for the new movement restrictions, and let that run overnight. The next day it was still running, so I spent some time trying to think of a way to speed it up. Didn't really get anywhere on my own, so I started reading up on A* to refresh my memory on how it worked.

The solution that I arrived at for the rewrite was to use Dijkstra's algorithm to pre-compute a map of what the minimum possible costs would be from each tile to the goal, if adjacent tiles could be moved to without restriction. I then used that as the heuristic for A*. While I was writing this, the original part 2 program did finish and gave the correct answer. Since I was already this far in though, I figured I'd finish the rewrite anyway.

The new program got the wrong answer, but did so very quickly. It turned out that I had a bug in my Dijkstra map. I was sorting the node queue by the currently computed cost to move from that node to the goal, when it instead should have been sorted by that plus the cost to enter that node from a neighbor. Since the node at the head of the queue is removed and marked as finalized on each iteration, some nodes were being finalized before their actual minimum costs were found.

When using the A* algorithm, you usually want your heuristic cost estimate to underestimate the actual cost to reach the goal from a given node. If it overestimates instead, the algorithm will overlook routes that are potentially more optimal than the computed route. This can be useful if you want to find a "good enough" route quickly, but in this case we need the actual best path.

• Day 17, part 1 (1 hour)

The volatility is dampened as more people start using it, including using it as an investment. Dampened volatility makes it a worse investment, but a better currency. If you analyze Bitcoin's price history, you'll see that it used to be more volatile than it currently is. This trend is likely to continue, barring some sort of catastrophic failure of the system.

Looks like this fix for nimsuggest didn't make it in though, so I'm still on devel for now.

Nim

I'm caught up!

This one was pretty straighforward. Iterate through the beam path, recursively creating new beams when you hit splitters. The only gotcha is that you need a way to detect infinite loops that can be created by splitters. I opted to record energized non-special tiles as - or |, depending on which way the beam was traveling, and then abort any path that retreads those tiles in the same way. I meant to also use + for where the beams cross, but I forgot and it turned out not to be necessary.

Part 2 was pretty trivial once the code for part 1 was written.

• Day 16, part 1
• Day 16, part 2

Nim

Almost caught up. Not much to say about this one. Part 1 was a freebie. Part 2 had a convoluted description, but was still pretty easy.

• Day 15, part 1
• Day 15, part 2

Nim

Getting caught up slowly after spending way too long on day 12. I'll be busy this weekend though, so I'll probably fall further behind.

Part 2 looked daunting at first, as I knew brute-forcing 1 billion iterations wouldn't be practical. I did some premature optimization anyway, pre-calculating north/south and east/west runs in which the round rocks would be able to travel.

At first I figured maybe the rocks would eventually reach a stable configuration, so I added a check to detect if the current iteration matches the previous one. It never triggered, so I dumped some of the grid states and it became obvious that there was a cycle occurring. I probably should have guessed this in advance. The spin cycle is effectively a pseudorandom number generator, and all PRNGs eventually cycle. Good PRNGs have a very long cycle length, but this one isn't very good.

I added a hash table, mapping the state of each iteration to the next one. Once a value is added that already exists in the table as a key, there's a complete cycle. At that point it's just a matter of walking the cycle to determine it's length, and calculating from there.

• Day 14, part 1
• Day 14, part 2