34
π - 2023 DAY 5 SOLUTIONS -π
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Dec 2023
34 points (100.0% liked)
Advent Of Code
736 readers
1 users here now
An unofficial home for the advent of code community on programming.dev!
Advent of Code is an annual Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.
AoC 2023
Solution Threads
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 |
Rules/Guidelines
- Follow the programming.dev instance rules
- Keep all content related to advent of code in some way
- If what youre posting relates to a day, put in brackets the year and then day number in front of the post title (e.g. [2023 Day 10])
- When an event is running, keep solutions in the solution megathread to avoid the community getting spammed with posts
Relevant Communities
Relevant Links
Credits
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
console.log('Hello World')
founded 1 year ago
MODERATORS
Nim
Woof. Part 1 was simple enough. I thought I could adapt my solution to part 2 pretty easily, just add all the values in the ranges to the starting set. Worked fine for the example, but the ranges for the actual input are too large. Ended up taking 16gb of RAM and crunching forever.
I finally abandoned my quick and dirty approach when rewriting part 2, and made some proper types and functions. Treated each range as an object, and used set operations on them. The difference operation tends to fragment the range that it's used on, so I meant to write some code to defragment the ranges after each round of mappings. Forgot to do so, but the code ran quick enough this time anyway.
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !nim@programming.dev
That's smart. Honestly, I don't understand how it works. π
I've got different solution from yours, but this part is the same, lol. My code slices the ranges into 1-3 parts on each step, so I also planned to 'defragment' them. But performance is plenty without this step, ~450 microseconds for both parts on my PC.
"Set operations" should probably be in quotes. I just mean that I implemented the
*(intersection) and-(difference) operators for my ValueRange type. The intersection operator works like it does for sets, just returning the overlap. The difference operator has to work a little differently, because ranges have to be contiguous, whereas sets don't, so it returns a sequence of ValueRange objects.My ValueMapping type uses a ValueRange for it's source, so applying it to a range just involves using the intersection operator to determine what part of the range needs to move, and the difference operator to determine which parts are left.
Well, then we have the same solution but coded very differently. Here's mine.
ruleAppliedis one function with almost all logic. I take a range and compare it to a rule's source range (50 98 2 is a rule). Overlaps get transformed and collected into the first sequence and everything that left goes in the second. I need twoseqs there, for transformed values to skip next rules in the same map.Repeat for each rule and each map (seq[Rule]). And presto, it's working!
Yeah, roughly the same idea. I guess I could have just used HSlice for my range type, I thought maybe there was some special magic to it.
It looks like your if-else ladder misses a corner case, where one range only intersects with the first or last element of the other. Switching to
<=and>=for those should take care of it though.Thank you, should be fixed now.