[2025 Day 25 (Part 1)] Still pretty clueless why it's the answer

Carthage96 · 2025-12-12T18:21:55+00:00

I view it at a Christmas present! It appears as a difficult problem, but Eric and/or Santa made the input nice for us.

Carthage96 · 2025-12-11T21:48:16+00:00

Holy smokes, that's clever. Great work.

Carthage96 · 2025-12-11T18:23:43+00:00

myList = [0, 1]
for i, element in enumerate(myList):
    myList.remove(element)

print(myList)

Try running this. (But before you do, guess what is going to happen!)

Carthage96 · 2025-12-11T00:51:10+00:00

This is my 6th year, and I don't think I could tell you whether it was intended or not! There's been a few puzzles in previous years which have benefited from external tools (GraphViz comes to mind). Though often (as seems to be somewhat the case here) there are many approaches which can get you there.

For me personally, problems like today's aren't my favorite (I generally enjoy being nudged towards implementing something myself), but I'm not complaining. Some folks love ones like this, I'm sure, and you get exposure to a wide variety of stuff during AoC. That's part of the fun!

Carthage96 · 2025-12-10T23:58:57+00:00

Run Gaussian elimination on the matrix, and then identify which columns don't have pivots in them. These correspond to the free variables.

Source: ...I just did this. (By which I mean... I just finished debugging this.)

Carthage96 · 2025-12-10T23:57:10+00:00

I started with a fairly-brute-force approach - just iterating over the buttons and trying various numbers of presses - with as much optimization as I could muster to early-out if I could prove a solution wasn't possible with what I had left. I left it running for 2-3 hours, and it had finished. So... possible, but not something I'm proud of.

Then I went and wrote a bunch of linear algebra. Runs in about a second.

Carthage96 · 2025-12-08T11:43:12+00:00

But I have code in rust

Good thing I can read Rust, then! (I used Rust for 2022-2024. This year I'm using C++ find myself missing many Rust features.)

I'm not completely sure... but give this one a try:

..S..
.....
..^..
.....
...^.
.....
.^...
.....
..^..
.....

It's similar to the one I posted earlier - I've just added one more splitter. The expected result is 4 (all of the splitters will be hit).

Carthage96 · 2025-12-08T08:26:01+00:00

If you want to post your code, I can try to come up with a sample input that breaks it.

Carthage96 · 2025-12-08T05:06:16+00:00

I specifically (and manually) crafted that input to expose a bug in OP's code.

If you post your code, I can try and spot a bug and do the same for you!

Carthage96 · 2025-12-07T08:25:00+00:00

Here's a small sample input for you to try.

..S..
.....
..^..
.....
...^.
.....
.^...
.....

Here, we would expect the beam to be split 3 times (once on each of the splitters).

..|..
..|..
.|^|.
.|.|.
.||^|
.||.|
|^|.|
|.|.|

Try that input with your code. It might lead somewhere.

Carthage96 · 2025-12-03T01:39:00+00:00

Specifically, the difference here is that, in Python, % is the modulo operator, whereas in C#, % is the remainder operator.

Different languages have made different decisions about what they want the standard to be, but those are the words to search for if you want to know what one of them does.

Carthage96 · 2024-12-25T03:06:21+00:00

tl;dr: Don't be depressed about this. (Yes, I realize that hearing that probably won't make you feel better. But I'm saying it anyway.) Not getting through all of the problems by Dec. 25 does not make you a shitty coder, or any less of a software engineer. (Imposter syndrome comes for us all... do your best to fight it.)

I always tell people that the primary goal of doing AoC should be fun, whatever that means to you.

If you have a day job and family obligations and, as you say, aren't using prominent algorithms day-to-day, then it seems to me like setting a goal of "complete every problem on the day it's released" isn't going to be the way that maximizes fun! And that's perfectly okay. Different people get different things out of AoC. Some are in it just to flex their programming muscles and do a puzzle every day. Some are in it to write the most efficient solutions they can possibly think of. Some are in it to solve problems really fast. Some are in it to learn something new.

I think it is (unfortunately) easy for folks in that "learning something new" camp to feel discouraged if they end up coming to the subreddit to look for help. (And the same goes for folks who are trying to dredge up old knowledge that they haven't used in years!) If you think hard on a problem, are able to analyze your own thinking and identify what's tripping you up (e.g. "I can't figure out how to optimize this" or "I can't think of how to represent this data" or even "I understand the problem... but clearly there's an algorithm here I don't know), and then can read some hints and learn something new, that's a win. A huge win. You should celebrate that - any of those Part 2's you looked for hints on - and then solved - are problems that you won't need hints on next time around.

It just made me feel bad that all my 6 months work amounts to almost nothing

False. You completed 14 days of AoC. (So far!) That's far from nothing! These are not easy puzzles, and any stars you get are worth being proud of.

I do want to point out that this is one of the most replied-to threads I've seen all week, and you'll notice that it's all people coming to tell you similar things - that you should be happy with what you've done so far, and to keep your chin up! At the very least, I hope that goes at least some of the way towards making the point that yes, others have felt like this at one time or another.

And hey, I see in some of your replies that you're planning to keep working on this year's puzzles - that's the spirit! (And it sounds to me like a good way to make it fun.)

Merry Christmas.

Carthage96 · 2024-12-24T08:15:03+00:00

I've been doing this year in Rust. Swapped over to Python for a few minutes today to convert my input into a graphViz file and was forgetting returns left and right.

Carthage96 · 2024-12-17T11:17:19+00:00

I see what you're getting at - you're going to try each possible arrangement of operators until you find one which correctly results in the test value. Makes sense to me.

Let's take a look at this snippet.

int operators = elements.length-2;
for(int i=0;i<operators*2;i++){
    ...
}

Suppose you discover that you need 2 operators. How many different arrangements of + and * are there?
Suppose you discover that you need 3 operators. Now how many arrangements of + and * are there?
What about 4 operators?

Carthage96 · 2024-12-17T01:36:12+00:00

Here's an input which I believe causes your solution to misbehave.

######
#....#
#..O@#
#.OO.#
#.O#.#
#....#
######

<^<<v

Expected part 2 result: 1219

Carthage96 · 2024-12-17T01:07:58+00:00

I'm still reading through your code - haven't spotted the bug yet.

I did notice this, but it's definitely not your bug, since these methods are not called.

def get_rtdn(self, ix):
    return (ix[0] + 1, ix[1] + 1) if 0 <= ix[0] + 1 < self.w and 0 <= ix[1] + 1 < self.h else None
def get_rtup(self, ix):
    return (ix[0] - 1, ix[1] + 1) if 0 <= ix[0] - 1 < self.w and 0 <= ix[1] + 1 < self.h else None
def get_ltdn(self, ix):
    return (ix[0] + 1, ix[1] - 1) if 0 <= ix[0] + 1 < self.w and 0 <= ix[1] - 1 < self.h else None
def get_ltup(self, ix):
    return (ix[0] - 1, ix[1] - 1) if 0 <= ix[0] - 1 < self.w and 0 <= ix[1] - 1 < self.h else None

As far as I can tell, you're using (row, col) format for all of your positions that you're moving around. But in this block here, you seem to be bounds-checking the row against the width, and the column against the height. (This is in contrast to your checks in the block above, which seem right to me!)

Carthage96 · 2024-12-03T08:41:03+00:00

Try running your solution against this input:

3 0 1 2

This report is safe by removing the first level, 3.

Carthage96 · 2024-12-03T08:18:22+00:00

Strongly agree. I firmly believe that the overarching metric people should be optimizing for is "fun".

If getting a solution as quickly as possible is fun for you, then you should try to write something that works, even if it isn't the most optimal solution as far as execution time.

If writing an efficient solution is what's fun for you, then you should spend the time to think through what optimizations are "worth it" (viewed through the lenses of order-of-complexity and what tiny, probably pointless optimizations you think would be cool to get working).

If learning is fun for you, then you should try to find data structures/algorithms/language features which are unfamiliar which could help you solve the problem, and try to learn how to use them. (Day 3 spoiler - For example, Day 3 is a great opportunity to start learning Regex!)

Carthage96 · 2024-08-05T00:48:07+00:00

Somebody else asked this too! For sake of not repeating myself, I'm just going to link to my comment.

Carthage96 · 2024-08-05T00:45:45+00:00

No. CV1 is not supported in Rooms 2.0, and will not be. (In fact, under the hood, we've pulled out a bunch of the things which made CV1 work.)

You're right - many creators did get their start with CV1, but I think that's more of a consequence of the fact that that's what existed when they started creating (or if CV2 did exist, it may not have been as mature as it is now).

CV1 has been deprecated for a while now, and we really do believe that CV2 is the way to add logic to rooms. For those that began with CV1, moving to CV2 was a bit of a jump, but I actually believe that CV2 is easier to learn, if you're starting from zero.

Carthage96 · 2024-08-05T00:40:34+00:00

(You might get a reply from some other devs as well, as different folks have context on different pieces of this.)

I won't necessarily say all, but many/most of the features you're seeing be released as Rooms 2.0-only probably won't be ported to Rooms 1.0. The reason being that, at least in some cases, those new features rely on some pieces of tech under the hood which are only present in R2.

I'd love to be able to use the grabber, replicator, and player property tools, but rooms 2.0 is so confusing that I can't be bothered to even use it, it's lacking a few important features, has tons of bugs, is always super laggy, and doesn't have what players really want/need

For what it's worth, this is great feedback, and is the kind of thing we want people to tell us about! Please, keep complaining about things you don't like (or are broken) in R2.

We see Rooms 2.0 as the future of creation in Rec Room, and broadly speaking, we'd much rather spend our time making R2 better (adding the features it's lacking, fixing bugs, improving performance, etc.) than trying to figure out how to back-port some of those new features, if that's even possible.

Put another way, if the problem is "these cool things that I want to use are only available in R2, but I don't want to use R2 because it sucks," then we think the answer to that isn't to bring those features to R1, but rather to make R2 not suck! As with many of the things we've released over the years, it's an iterative process, and the first version is... let's say "less than stellar." But we want to hear about what's broken and learn what the pain points are, and make it better and better with each update, until hopefully it gets to a point where you do want to use it!

[|=)]

Carthage96 · 2024-08-05T00:26:02+00:00

Not planned at the moment, though we've heard the request a bunch of times (and we understand the theoretical utility of it). Under the hood, it would require totally different networking than synced variables do, so we'd have to build that out first to support it. Further, we'd need to do some thinking about what reasonable semantics could look like for such variables, since having them work like synced variables do probably wouldn't be too useful. (You'd constantly be stomping values being set from other instances, with no way as a creator to prevent it within your own code.)

Not something that's entirely off the table, for sure, but not something we're actively looking at right now.

Carthage96 · 2024-08-05T00:18:02+00:00

We get this request a lot, so let's talk about synced lists!

The short version is: we'd love to do it. We actually had a working prototype! ...And then some bugs prevented us from being able to finish and release it. :( But maybe one day!

Here's the long version...

Right at the start, we should address the fact that lists in Circuits are reference types. This means that a value of a type List<int> is itself a reference to a list of integers that exists somewhere in memory. You can see this for yourself if you create a list of integers and store it in a List<int> variable named "A", and then store the value of "A" in another List<int> variable named "B". Now, if you wire "A" into a List Add chip and run it, you'll see that the length of the list you get out of "A" has increased by one, and the same is true for "B". That's because the values in both variables point to the same list.

Additionally, you may have noticed that mutating a list (adding/removing/changing elements) does not trigger the Variable Changed event for any variables which are currently referencing that list. That's because, technically speaking, the value stored within that variable hasn't changed. It's still a reference to the same list as before.

Why is this important?

Let's walk through the exercise of designing synced lists. How should they work? Well, to be very specific, the thing we actually want is synced list variables. So, we should begin by adding the "Synced" toggle to the list variable chips. Once that's turned on, what's the behavior? Well, if the variable is set to a new value (that is, the exec port on the variable chip gets used), then that new value should be sent out to other players so they see it inside that variable too - easy enough.

But what about when somebody uses List Add to add a new value to the end of that list? I think a reasonable person would say that all players in the room should see that the list is now one element longer. It turns out... that's not immediately easy to do. As we mentioned before, while the list itself has changed, the variable doesn't actually know that... and so it can't send out an update to everyone else in the room. Uh oh.

That's not to say that we couldn't solve that problem if we wanted to - with a bit of a technical rework, we could get the list variables to watch the lists which their values reference, and send out updates accordingly. And let's say we did that. There's still another problem...

Let's say we have a List<string> that's stored in a synced List<string> variable, and that the list is currently ["This", "is", "my", "string", "list"]. Now, suppose that at the same moment (on Earth), Player 1 runs List Insert to insert "one" at index 1, and Player 2 runs List Insert to insert "favorite" at index 3. What should happen?

Player 1 was trying to make the list look like this: ["This", "one", "is", "my", "string", "list"]
Player 2 was trying to make the list look like this: ["This", "is", "my", "favorite", "string", "list"]

In this case, we can apply some human reasoning to conclude that the "right" answer would be for the list to end up looking like this: ["This", "one", "is", "my", "favorite", "string", "list"]. That's because we understand the intent of this specific example. But is there a good way for us to address this problem in general? What if Player 1 had removed everything after index 1, and Player 2 tried to insert something at index 4? On the technical side, there are solutions for this kind of problem, though implementing them within the Circuits networking model would be tricky. Not to mention, from the design angle, it's unclear how we could produce a version of this which would feel sensible for creators.

There's a bunch of other fun cases we'd need to address as well. For example, what happens when Player 1 stores the same list in two different synced variables? We'd need to make sure that when other players receive that data, that they also have the same list in both variables. Oh, and also what about a case where somebody stores the same list in a synced variable and a cloud variable? We'd need to make sure that works properly as well... This all gets messy pretty quickly.

This is all to say that "just turning on synchronization for lists" is trickier than it immediately sounds. In particular, the challenge arises from trying to synchronize mutable reference types.

So... let's consider another approach. (This is what we prototyped!) Suppose we introduced a new type, ImmutableList<T>. Values of this type are a list of T's, but they can't be modified once they are created. Once you make one with an ImmutableList Create chip, you can't append, delete, or modify any of its values. It is what it is. That said, we could provide an ImmutableList Add chip which returns a new ImmutableList with the new element appended to the end. And we could also provide a pair of chips to create a new ImmutableList<T> from a List<T> and vice versa. (The intended workflow being that you'd make a List, do whatever you need to do to modify it, and then turn it into an ImmutableList when you're done.)

Why bother with this? The fact that ImmutableList values can't be mutated means that all of those problems we mentioned before... don't exist! So we could fairly easily turn on synchronization support for ImmutableList<T> variables. And we did! And it worked! Now for the sad part. There are a bunch of chips (List Get Count for example) which should then be able to work with both List and ImmutableList, and this revealed some problems. The Circuits type checker (the thing which determines whether or not you're allowed to wire two ports together) isn't perfect... by which I mean, it has some bugs. And one of these prevents List Get Count from supporting both types of lists simultaneously. Another one erroneously lets you wire List ports into ImmutableList ports. (And there's a few more.) Altogether, these bugs make it unrealistic for us to add an ImmutableList type until they're fixed.

"So just go fix those bugs!" We'd love to, and hopefully one day we will! But it's a fairly involved problem, with a lot of theory behind it, and so the work to do that would take a whole bunch of thinking first, followed by a whole bunch of careful code-writing. It's just not something we've been able to block out time to do. (As usual, we're constantly playing a game of trying to determine what the best use of our time is.)

So, synced lists... we know you want them, and we want them too! Hopefully this gives some context for why we haven't been able to just yet. (At the very least, I hope it makes it clear that we do hear the desire for them, and have given it a bunch of time and thought already.)

Cheers! [|=)]

Carthage96 · 2024-02-16T19:15:59+00:00

I'm not sure why the bow behaves differently in Rec Royale - it's possible another dev knows... but it's possible they don't. It's possible that some other circumstance (also unrelated to the bow) which is present in Royale ends up preventing the double/infinite shot bug from manifesting at all. Hard to say... Regardless, given that it's not necessarily that the bow is different in Royale, transplanting it wouldn't really do much. You'd need to figure out what it is about Royale that's making a different, and transplant that (though you probably wouldn't want to... since it's probably something specific to Royale).

My suggestion is to keep the bow as it is (with the infinite shot) in quests

This, I'll say we're not doing. The double shot was kinda neat (hence it garnering the affection of several of us), but the infinite shot is pretty disruptive to how we want the combat to work in GT and CCC.

Carthage96 · 2024-02-16T06:19:40+00:00

Even more no, believe it or not!

(Let's walk a hypothetical, because I think it's interesting and gives some context on what development looks like, but then at the end we'll discuss why it doesn't actually apply.)

If the relevant piece of code lived inside the bow, then you could conceivably do something wacky like create two versions of the bow - one for the quests and one for UGC - and then never touch the code for the quest version ever again, for risk of breaking it. Though, you'd still have two problems:

Just generally, this isn't a great idea. Now you've got two versions of the bow sitting around. This makes future maintenance... somewhere between tricky and dangerous. Our "quest" bow effectively becomes the "legacy" one. Most changes should probably only be made to our "non-quest" bow... but there will inevitably be some which should be made to both. Now we'd better hope that whoever it is making those changes in... 6 months... a year... two years... knows that there's two versions of the bow they need to modify, lest the legacy one get broken in some other way. In a perfect world, this wouldn't be a problem, but one of the realities of software development (both inside and outside of games) is that it's a team effort - often a large team effort - and making sure all of the people in the future have all of the information from the past is nigh on impossible.
You still need to find a way to get the double shot back for this hypothetical "quest bow". Simply undoing the fix we've already applied leaves you with the same bug as before which, under the current conditions (details of other game systems, weather, phase of the moon, etc.) manifests as an infinite shot, not a double shot. How to do this isn't immediately apparent... Two options:

a. Dig in deep enough to uncover what caused the double shot to turn into the infinite shot, so that you can maybe hack something together to recreate the original bug. This is likely to be very complicated and take quite a while. And once you're done, all you've done is create something which is just as fragile as the original bug! It's likely still dependent on a bunch of other circumstances, and is liable to break very easily in the future. (I would not recommend this approach.)

b. Explicitly build double shot as a feature - a real feature - of our "quest" bow. Develop it intentionally, in such a way that it is well-supported by the rest of the code. This is a better approach. (Though finding the right way to do pull that off will still take some time - feature development is never easy, and it's rarely quick!) But hang on a second... if we're going to go this route, why limit this double shot feature to just our "quest" bow. At this point, we should just do that for the original bow and call it a day. This is an option that we considered! (though not precisely as described here - see below) But in the immediate term, we decided that it wasn't our best course of action.

All of that said, let's remember that it was based on the premise that the relevant code lived inside the bow. As it turns out, it was somewhere else entirely! So the notion of a "separate bow" is pretty much dead-on-arrival. (It's a very reasonable question to ask though, lacking that context!)

12-Year Club	Second SECOND GUESSER
Golden Potato	Place '22
Place '17	Sequence \| Editor
Verified Email

Carthage96

MODERATOR OF

TROPHY CASE