🌟 - 2023 DAY 6 SOLUTIONS -🌟
Day 6: Wait for It
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
Today was easy enough that I felt confident enough to hammer out a solution in Uiua, so read and enjoy (or try it out live):
Rust
I went with solving the quadratic equation, so part 2 was just a trivial change in parsing. It was a bit janky to find the integer that is strictly larger than a floating point number, but it all worked out.
(number+1).floor()does the trickOh yeah, that's clever. I'll remember that when it comes up again.
In Python when using numpy to find the roots, sometimes you get a numeric artifact like 30.99999999999, which breaks this. Make sure to limit the significant digits to a sane amount like 5 with rounding to prevent that.
I wanted to try the easy approach first and see how slow it was. Didn't even take a second for part 2. So I just skipped the mathematical solution entirely.
Nim
Hey, waitaminute, this isn't a programming puzzle. This is algebra homework!
Part 2 only required a trivial change to the parsing, the rest of the code still worked. I kept the data as singleton arrays to keep it compatible.
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]
Haskell
This problem has a nice closed form solution, but brute force also works.
(My keyboard broke during part two. Yet another day off the bottom of the leaderboard...)
Rust
Feedback welcome! Feel like I'm getting the hand of Rust more and more.
It's caused by lemmy code blocks. They don't handle
&correctly. See.I'm no rust expert, but:
you can use
into_iter()instead ofiter()to get owned data (if you're not going to use the original container again). Withinto_iter()you dont have to deref the values every time which is nice.Also it's small potatoes, but calling
input.lines().collect()allocates a vector (that isnt ever used again) whenlines()returns an iterator that you can use directly. You can instead passlines.next().unwrap()into your functions directly.Strings have a method called
split_whitespace()(also asplit_ascii_whitespace()) that returns an iterator over tokens separated by any amount of whitespace. You can then call.collect()with a String turbofish (i'd type it out but lemmy's markdown is killing me) on that iterator. Iirc that ends up being faster because replacing characters with an empty character requires you to shift all the following characters backward each time.Overall really clean code though. One of my favorite parts of using rust (and pain points of going back to other languages) is the crazy amount of helper functions for common operations on basic types.
Edit: oh yeah, also strings have a
.parse()method to converts it to a number e.g.data.parse()where the parse takes a turbo fish of the numeric type. As always, turbofishes arent required if rust already knows the type of the variable it's being assigned to.Thanks for making some time to check my code, really appreciated! the split_whitespace is super useful, for some reason I expected it to just split on single spaces, so I was messing with trim() stuff the whole time :D. Could immediately apply this feedback to the Challenge of today! I've now created a general function I can use for these situations every time:
Thanks again!
Dart Solution
I decided to use the quadratic formula to solve part 1 which slowed me down while I struggled to remember how it went, but meant that part 2 was a one line change.
This year really is a roller coaster...
Scala3
Raku
I spent a lot more time than necessary optimizing the count-ways-to-beat function, but I'm happy with the result. This is my first time using the | operator to flatten a list into function arguments.
edit: unfortunately, the lemmy web page is unable to properly display the source code in a code block. It doesn't display text enclosed in pointy brackets <>, perhaps it looks too much like HTML. View code on github.
::: spoiler Code
:::
A nice simple one today. And only a half second delay for part two instead of half an hour. What a treat. I could probably have nicer input parsing, but that seems to be the theme this year, so that will become a big focus of my next round through these I'm guessing. The algorithm here to get the winning possibilities could also probably be improved upon by figuring out what the number of seconds for the current record is, and only looping from there until hitting a number that doesn't win, as opposed to brute-forcing the whole loop.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day06.rs
C
Brute forced it, runs in 60 ms or so. Only shortcut is quitting the loop when the distance drops below the record. I didn't bother with the closed form solution here because a) it ran so fast and b) I was concerned about floats, rounding and off-by-one errors. Will probably implement it later!
GitHub link
Edit: implemented the closed form solution. Feels dirty copying a formula without really understanding it..
GitHub link (closed form)
Yes, thank you!
A nice change of pace from the previous puzzles, more maths and less parsing :::spoiler Python
[Language: Lean4]
This one was straightforward, especially since Lean's Floats are 64bits. There is one interesting piece in the solution though, and that's the function that combines two integers, which I wrote because I want to use the same parse function for both parts. This
combineNumbersfunction is interesting, because it needs a proof of termination to make the Lean4 compiler happy. Or, in other words, the compiler needs to be told that if n is larger than 0, n/10 is a strictly smaller integer than n. That proof actually exists in Lean's standard library, but the compiler doesn't find it by itself. Supplying it is as easy as invoking thesimptactic with that proof, and a proof that n is larger than 0.As with the previous days, I won't post the full source here, just the relevant parts. The full solution is on github, including the main function of the program, that loads the input file and runs the solution.
::: spoiler Solution
:::
Crystal
[JavaScript] Relatively easy one today
Paste
:::spoiler Part 1
::: :::spoiler Part 2
:::
Was a bit late with posting the solution thread and solving this since I ended up napping until 2am, if anyone notices theres no solution thread and its after the leaderboard has been filled (can check from the stats page if 100 people are done) feel free to start one up (I just copy paste the text in each of them)
Well, this one ended up being a really nice and terse solution when done naïvely, here with a trimmed snippet from my simple solution;
:::spoiler Ruby
:::
Nim
Today's puzzle was too easy. I solved it with bruteforce in 20 minutes, but that's boring. So here's the optimized solution with quadratic formula.
Total runtime: 0.008 ms
Puzzle rating: Too Easy 5/10
Code: day_06/solution.nim
That was so much better than yesterday. Went with algebra but looks like brute force would have worked.
::: spoiler python
:::
Language: Python
::: spoiler Part 1
Not much to say... this was pretty straightforward.
:::
::: spoiler Part 2
Probably could have done some math, but didn't need to :]
:::
GitHub Repo
Golang
Pretty straightforward. The only optimization I did is that the pairs are symmetric (3ms hold and 4ms travel is the same as 4ms hold and 3ms travel).
::: spoiler Part 1
:::
::: spoiler Part 2
:::
ah damn, didn't think of the symmetric pairs
Today's problems felt really refreshing after yesterday.
Solution in Rust 🦀
View formatted code on GitLab
::: spoiler Code
:::
Factor on github (with comments and imports):
I didn't use any math smarts.
C++
Yesterday, I decided to code in Tcl. That program is still running, i will go back to the day 5 post once it finishes :)
Today was super simple. My first attempt worked in both cases, where the hardest part was really switching my ints to long longs. Part 1 worked on first compile and part 2 I had to compile twice after I realized the data type needs. Still, that change was made by search and replace.
I guess today was meant to be a real time race to get first answer? This is like day 1 stuff! Still, I have kids and a job so I did not get to stay up until the problem was posted.
I used C++ because I thought something intense may be coming on the part 2 problem, and I was burned yesterday. It looks like I spent another fast language on nothing! I think I'll keep zig in the hole for the next number cruncher.
Oh, and yes my TCL program is still running...
My solutions can be found here:
Not sure if it's the most optimal, but I figured it's probably quicker to calculate the first point when you start winning, and then reverse it to get the last point when you'll last win. Subtracting the two to get the total number of ways to win.
Takes about 3 seconds to run on the real input
::: spoiler Python Solution class Race: def init(self, time, distance): self.time = time self.distance = distance
:::