🎁 - 2023 DAY 5 SOLUTIONS -🎁
Day 5: If You Give a Seed a Fertilizer
Megathread guidelines
- Keep top level comments as only solutions, if you want to say something other than a solution put it in a new post. (replies to comments can be whatever)
- Code block support is not fully rolled out yet but likely will be in the middle of the event. Try to share solutions as both code blocks and using something such as https://topaz.github.io/paste/ , pastebin, or github (code blocks to future proof it for when 0.19 comes out and since code blocks currently function in some apps and some instances as well if they are running a 0.19 beta)
FAQ
- What is this?: Here is a post with a large amount of details: https://programming.dev/post/6637268
- Where do I participate?: https://adventofcode.com/
- Is there a leaderboard for the community?: We have a programming.dev leaderboard with the info on how to join in this post: https://programming.dev/post/6631465
🔒This post will be unlocked when there is a decent amount of submissions on the leaderboard to avoid cheating for top spots
🔓 Unlocked after 27 mins (current record for time, hard one today)
35 replies
Rust
Ooof. Part 1 was easy enough, but for part two I initially went with the naive solution of trying every single seed which took more than a minute (I never really measured). Although that got me the right answer, to me that was just unacceptable.
I proceeded to try and combine all mappings into one but gave up after spending way too much time on it.
Then I had the idea that the lowest number in the end must lie at the beginning of a range somewhere. Either the start of a seed range in the beginning or the start of a range in one of the mappings. Any in-between numbers must end up with a higher result. So I considered the start points of all ranges, went through the mappings in reverse to find out if that point is actually within a seed range, and only tested those starting points.
Finally I had only 183 points to test which ran much faster (0.9ms).
This really helped me out. I was stuck on either trying every single seed, or working backwards and trying every single location from 0 to infinity, and couldn't wrap my head around how to filter down the list to be manageable. Your comment made it all make sense.
In the end, was able to work backwards with the 172 lowest locations in each range to get potential seeds, and from there was able to get a short list of 89 valid seeds (including the original seed values) to then figure out which one has the shortest location.
Thanks!
I'm a little confused about this one. The mappings are total, that is any number that is not defined explicitly gets mapped to itself. So it's easy to create an example where the lowest number does not get mentioned within a range:
Here, we have seeds 0, 1 and 2. seed 0 gets mapped to location 10, seed 1 gets mapped to location 11 and seed 2 gets mapped to location 2. That means location 2 would be the answer, but it's not a start of any range. I guess this just doesn't happen in any of the inputs?
EDIT: actually it's double weird. If you implemented a backwards search, that is you create reverse mappings and then try out all locations (which is what I and many others did), the result of the above example is location 0, whereas if you create a forwards brute force of all seeds, the result is 2. For the reverse approach to work in all cases, the mappings would have to be bijective.
Indeed, my solution fails on this input (returns 10, which is the location to seed 0), but it can be easily solved by also adding the ends of each range as well.
Maybe the input was quite forgiving. Thinking about it more, reversing the mapping can get quite involved, because it is neither surjective nor injective, so the inverse can actually have any number of results.
In your example there is no input that maps to 0, but there are two inputs that map to 11 (1 and 11). If the seed-to-soil map also included
10 20 2, 21 would also map to 11.[JavaScript] Well that was by far the hardest out of all of the days, part 1 was relatively fine but part 2 took me awhile of trying different things
Ended up solving it by working backwards by trying different location values and seeing if that can become a valid seed. Takes around 3 secs to compute the answer.
Link to code
:::spoiler Part 1 Code Block
::: :::spoiler Part 2 Code Block
:::
Torn between doing the problem backwards and implementing a more general case -- glad to know both approaches work out in the end!
Huh, that's clever.
Turns out I got really lucky and my location value is much lower than most peoples which is why it can be solved relatively quickly
Haskell
Not hugely proud of this one; part one would have been easier if I'd spend more time reading the question and not started on an overly-general solution, and I lost a lot of time on part two to a missing
a +. More haste, less speed, eh?Odin
When I read the problem description I expected the input to also be 2 digit numbers. When I looked at it I just had to say "huh."
Second part I think you definitely have to do in reverse (edit: if you are doing a linear search for the answer), as that allows you to nope out as soon as you find a match, whereas with doing it forward you have to keep checking just in case.
Formatted code
Finally. :cries:
Part 1 was fine, I was figuring I might be able to practice classes.
Part 2 told me that nope, memory management required for you. In the end instead of calculating seeds, I resolved the whole thing down to a single mapping of seeds to locations. Then I could just sort by location ranges and try to see if they were a seed. Code is full of old parts from failed solutions but I've had enough of day 5, so I no longer care to clean it up.
Like many others, I really didn't enjoy this one. I particularly struggled with part 02, which ended up with me just brute forcing it and checking each seed. On my system it took over 15 minutes to run, which is truly awful. I'm open to pointers on how I could better have solved part two.
Solution in Rust 🦀
Formatted Solution on GitLab
::: spoiler Code
:::
I got far enough to realize that you probably needed to work backwards and given a location, determine the accompanying seed, and then check if that seed is one of the ones listed in the range. Still though, starting at 0 for location and working up was taking forever to find the first valid seed
Someone in this thread pointed out that if you picked the first value of each range in the map, working backwards from those points will get you a short list of seeds which map to low values. You then check if those seeds are valid, and also check the location of the first seeds in the range (the rest of the seeds in the range don't matter because those are covered by the first check). This ends up with about 200 locations which you can sort, to get the lowest value.
I tried brute forcing it but couldn't get the process to finish. Iterating through hundreds of millions of seeds is no bueno.
After reading your comment though I got the idea to map whole seed ranges instead of individual seeds. That finished in no time of course.
Scala3
kind of convoluted, but purely functional
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.
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.
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: ![email protected]
This was interesting! So iterating through the solution space would be infeasible here and it seems we need to look for boundaries between regions and follow them to find places where a solution could occur.
Python: https://pastebin.com/8Ckx36fu
[Language: Lean4]
I'll only post the actual parsing and solution. I have written some helpers (in this case particularly relevant: Quicksort) which are in other files, as is the main function. For the full code, please see my github repo.
This one also ended up quite long, because I couldn't resist to use different types for the different things, and to have the type checker confirm that I'm combining the maps between them in the correct order.
Also, I am not 100% certain that part 2 doesn't have any off-by-one errors. I didn't write any unit tests for it... The answer is correct though, so I probably didn't mess it up too horribly. Also, it is pretty fast. Part 2 takes about 1.2 milliseconds on my machine, and this is including the file parsing (but not the loading of the file).
It seems my solution is too long for a single post though, so I'll split off part 2 and post it separately.
Edit: There was a bug in the function that checks overlaps between ranges while parsing.
::: spoiler Parsing and Part 1
:::
::: spoiler Part 2
:::
[C]
My first approach to part 2 was to take the list of ranges, map it to a new list of (possibly split up) ranges, etc, but I realized that would take more memory and bookkeeping than I'd like. Scrapped it and rewrote it with recursion. Much cleaner and the benchmarks are still looking good! (But for how much longer?)
https://github.com/sjmulder/aoc/blob/master/2023/c/day05.c
Edit: I see some people went for looping from 0 to try possible answers. Clever and short but I wanted to go for a more efficient approach.
Ah, nice! Dealing with each range individually makes things much simpler.
Well, I can't say much about this one. The code is ugly, horribly inefficient, and part two takes a solid half hour to run. It got the right answer though, so that's something I suppose. I think something like
nomto parse the input would be much cleaner, and there's got to be a better way of going about part two than just brute forcing through every possible seed, but hey, it works so that's good enough for now.https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day05.rs
Nim
Part 1 was really easy.
Part 2, I struggled to solve efficiently, so I just ran naive bruteforce for 5 minutes until I got the answer.
Later, I've rewritten my solution for Part 2. The idea is to handle ranges as ranges, check seed ranges against map ranges, transform overlaps, but keep not-overlapping parts.
Total runtime after rewrite: ~ 0.4 ms.
Today's puzzle was nice - 8.5/10.
Code: day_05/solution.nim
CRYSTAL
finally solved part 2, and in just 1 second :)))
Language: Python
Github
Catching up missed days.
Language: Python
solution
Started 4 days late so coming up from behind. Day 5 was the first solution I am somewhat proud of. I used interval arithmetics. I had to somewhat extend a class interval from pyinterval into something I called PointedInterval. In the end part 2 was completed in 0.32 seconds. It does not reverse engineer the solution starting from 0 location and inverse mapping until you find a seed (that was how I was initially planning to do it). It maps forward everything as intervals. There is a bit of a boiler plate which is in the utils file.
RIP?
Language: Python
::: spoiler Part 1
The first part wasn't too bad... once I realized you should store the ranges and not actually generate all the numbers o_O.
:::
::: spoiler Part 2
This part took me forever, mostly to actually run, but also to fix a few off-by-one errors :|
Fortunately, I was able to re-use most of my code in Part A and just add a new function to search the range of seeds.
Even with
concurrent.futuresand a 24-core machine, it still took me about 30 - 45 minutes to complete with Python (that said, there were only 10 seed range s in the input, so I could only use 10 cores, and of those 5 of the ranges appeared to be really large, leading to a long tail effect).:::
GitHub Repo