The first part was simple enough. Adding in the 3 remaining tilt methods for star 2 was also simple enough, and worked just how I figured it would. Tried the brute force solution first, but realized it was going to take a ridiculous amount of time and went back to figure out an algorithm. It was simple enough to guess that it would hit a point where it just repeats infinitely, but actually coding out the math to extrapolate that took way more time than I want to admit. Not sure why I struggled with it so much, but after some pen and paper mathing, I essentially got there. Ended up having to subract 1 from this calculation, and either I'm just missing something or am way too tired, because I don't know why it's one less than what I thought it would be, but it works so who am I to complain.
Had to take a couple days off, but this was a nice one to come back to. Will have to find some time today to go back and do one or two of the 3 that I missed. I don't have much to say about this one - I had an idea almost immediately and it worked out without much struggle. There's probably some cleaner ways to write parts of this, but I'm not too disappointed with how it turned out.
That was a fun one. Especially after yesterday. As soon as I saw that star 1 was expanding each gap by 1, I just had a feeling that star 2 would be doing the same calculation with a larger expansion, so I wrote my code in a way that would make that quite simple to modify. When I saw the factor of 1,000,000 I was scared that it was going to be one of those processor-destroying AoC challenges where you either wait for 2 hours to get an answer, or have to come up with a fancy mathematical way of solving things, but after changing my i32 distance to an i64, it calculated just fine and instantly. I guess only storing the locations of galaxies and not dealing with the entire grid was good enough to keep the performance down.
Well, star one is solved. I don't love the code, but yet again, it works for now. I don't love the use of a label to continue/break a loop, and the valid_steps function is a mess that could probably be done much cleaner.
Upon looking at star 2 I don't even have the slightest idea of where to start. I may have to come back to this one at a later date. Sigh.
Two days, a few failed solutions, some misread instructions, and a lot of
manually parsing output data and debugging silly tiny mistakes... but it's
finally done. I don't really wanna talk about it.
A pretty simple one today, but fun to do. I could probably clean up the parsing
code (AKA my theme for this year), and create just one single vector instead of
having the original history separated out from all of the sequences, but this
is what made sense to me on my first pass so it's how I did it.
First part was simple enough. Second part was easy logically, but after running the brute force solution with a parallel iterator from rayon and maxing out all 12 cores of this CPU, it was still taking forever. I always get tripped up by these ones that need fancy math, because although I was always good at math, I've never been good at looking at these problems and figuring out what kind of formula would apply. So I cheated and looked at other people's comments for their solutions, and saw the least common multiple mentioned. This made sense to me, so I implemented it and got a result almost instantly. I hate having to look at other comments to solve these things, but I never would have came to that conclusion myself.
The code still isn't the cleanest, and I'd love to tidy up the parsing, but it works and I'm happy.
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.
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 nom to 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.
I enjoyed this one. It was a nice simple break after Days 1 and 3; the type of basic puzzle I expect from the first few days of Advent of Code. Pretty simple logic in this one, I don't think I would change too much. I'm sure I'll find a way to clean up how it's written a bit, but I'm happy with this one today.
Another day of the 2023 Advent of Code, and another day where I hate looking
at my code. This year just seems like it is starting off a lot more complex
than I remember in previous years. This one was a little tricky, but I got
there without any major setbacks. Another one I am excited to come back to and
clean up, but this first pass is all about getting a solution, and this one
works.
Not too tricky today. Part 2 wasn't as big of a curveball as yesterday thankfully. I don't think it's the cleanest code I've ever written, but hey - the whole point of this is to get better at Rust, so I'll definitely be learning as I go, and coming back at the end to clean a lot of these up. I think for this one I'd like to look into a parsing crate like nom to clean up all the spliting and unwrapping in the two from() methods.
Solved part one in about thirty seconds. But wow, either my brain is just tired at this hour or I'm lacking in skill, but part two is harder than any other year has been on the first day. Anyway, I managed to solve it, but I absolutely hate it, and will definitely be coming back to try to clean this one up.
impl Solver for Day01 {
fn star_one(&self, input: &str) -> String {
let mut result = 0;
for line in input.lines() {
let line = line
.chars()
.filter(|ch| ch.is_ascii_digit())
.collect::>();
let first = line.first().unwrap();
let last = line.last().unwrap();
let number = format!("{first}{last}").parse::().unwrap();
result += number;
}
result.to_string()
}
fn star_two(&self, input: &str) -> String {
let mut result = 0;
for line in input.lines() {
let mut first = None;
let mut last = None;
while first == None {
for index in 0..line.len() {
let line_slice = &line[index..];
if line_slice.starts_with("one") || line_slice.starts_with("1") {
first = Some(1);
} else if line_slice.starts_with("two") || line_slice.starts_with("2") {
first = Some(2);
} else if line_slice.starts_with("three") || line_slice.starts_with("3") {
first = Some(3);
} else if line_slice.starts_with("four") || line_slice.starts_with("4") {
first = Some(4);
} else if line_slice.starts_with("five") || line_slice.starts_with("5") {
first = Some(5);
} else if line_slice.starts_with("six") || line_slice.starts_with("6") {
first = Some(6);
} else if line_slice.starts_with("seven") || line_slice.starts_with("7") {
first = Some(7);
} else if line_slice.starts_with("eight") || line_slice.starts_with("8") {
first = Some(8);
} else if line_slice.starts_with("nine") || line_slice.starts_with("9") {
first = Some(9);
}
if first.is_some() {
break;
}
}
}
while last == None {
for index in (0..line.len()).rev() {
let line_slice = &line[index..];
if line_slice.starts_with("one") || line_slice.starts_with("1") {
last = Some(1);
} else if line_slice.starts_with("two") || line_slice.starts_with("2") {
last = Some(2);
} else if line_slice.starts_with("three") || line_slice.starts_with("3") {
last = Some(3);
} else if line_slice.starts_with("four") || line_slice.starts_with("4") {
last = Some(4);
} else if line_slice.starts_with("five") || line_slice.starts_with("5") {
last = Some(5);
} else if line_slice.starts_with("six") || line_slice.starts_with("6") {
last = Some(6);
} else if line_slice.starts_with("seven") || line_slice.starts_with("7") {
last = Some(7);
} else if line_slice.starts_with("eight") || line_slice.starts_with("8") {
last = Some(8);
} else if line_slice.starts_with("nine") || line_slice.starts_with("9") {
last = Some(9);
}
if last.is_some() {
break;
}
}
}
result += format!("{}{}", first.unwrap(), last.unwrap())
.parse::()
.unwrap();
}
result.to_string()
}
}
I've had the damn song stuck in my head since I saw this post.
The first part was simple enough. Adding in the 3 remaining tilt methods for star 2 was also simple enough, and worked just how I figured it would. Tried the brute force solution first, but realized it was going to take a ridiculous amount of time and went back to figure out an algorithm. It was simple enough to guess that it would hit a point where it just repeats infinitely, but actually coding out the math to extrapolate that took way more time than I want to admit. Not sure why I struggled with it so much, but after some pen and paper mathing, I essentially got there. Ended up having to subract
1from this calculation, and either I'm just missing something or am way too tired, because I don't know why it's one less than what I thought it would be, but it works so who am I to complain.https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day14.rs
Had to take a couple days off, but this was a nice one to come back to. Will have to find some time today to go back and do one or two of the 3 that I missed. I don't have much to say about this one - I had an idea almost immediately and it worked out without much struggle. There's probably some cleaner ways to write parts of this, but I'm not too disappointed with how it turned out.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day15.rs
That was a fun one. Especially after yesterday. As soon as I saw that star 1 was expanding each gap by 1, I just had a feeling that star 2 would be doing the same calculation with a larger expansion, so I wrote my code in a way that would make that quite simple to modify. When I saw the factor of 1,000,000 I was scared that it was going to be one of those processor-destroying AoC challenges where you either wait for 2 hours to get an answer, or have to come up with a fancy mathematical way of solving things, but after changing my
i32distance to ani64, it calculated just fine and instantly. I guess only storing the locations of galaxies and not dealing with the entire grid was good enough to keep the performance down.https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day11.rs
Well, star one is solved. I don't love the code, but yet again, it works for now. I don't love the use of a label to continue/break a loop, and the
valid_stepsfunction is a mess that could probably be done much cleaner.Upon looking at star 2 I don't even have the slightest idea of where to start. I may have to come back to this one at a later date. Sigh.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day10.rs
Two days, a few failed solutions, some misread instructions, and a lot of manually parsing output data and debugging silly tiny mistakes... but it's finally done. I don't really wanna talk about it.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day07.rs
A pretty simple one today, but fun to do. I could probably clean up the parsing code (AKA my theme for this year), and create just one single vector instead of having the original history separated out from all of the sequences, but this is what made sense to me on my first pass so it's how I did it.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day09.rs
First part was simple enough. Second part was easy logically, but after running the brute force solution with a parallel iterator from
rayonand maxing out all 12 cores of this CPU, it was still taking forever. I always get tripped up by these ones that need fancy math, because although I was always good at math, I've never been good at looking at these problems and figuring out what kind of formula would apply. So I cheated and looked at other people's comments for their solutions, and saw the least common multiple mentioned. This made sense to me, so I implemented it and got a result almost instantly. I hate having to look at other comments to solve these things, but I never would have came to that conclusion myself.The code still isn't the cleanest, and I'd love to tidy up the parsing, but it works and I'm happy.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day08.rs
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
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
I enjoyed this one. It was a nice simple break after Days 1 and 3; the type of basic puzzle I expect from the first few days of Advent of Code. Pretty simple logic in this one, I don't think I would change too much. I'm sure I'll find a way to clean up how it's written a bit, but I'm happy with this one today.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day04.rs
Another day of the 2023 Advent of Code, and another day where I hate looking at my code. This year just seems like it is starting off a lot more complex than I remember in previous years. This one was a little tricky, but I got there without any major setbacks. Another one I am excited to come back to and clean up, but this first pass is all about getting a solution, and this one works.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day03.rs
Not too tricky today. Part 2 wasn't as big of a curveball as yesterday thankfully. I don't think it's the cleanest code I've ever written, but hey - the whole point of this is to get better at Rust, so I'll definitely be learning as I go, and coming back at the end to clean a lot of these up. I think for this one I'd like to look into a parsing crate like nom to clean up all the spliting and unwrapping in the two from() methods.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day02.rs
Wow, I sure did. I was tired last night. I'll edit my solution in and fix my error.
Solved part one in about thirty seconds. But wow, either my brain is just tired at this hour or I'm lacking in skill, but part two is harder than any other year has been on the first day. Anyway, I managed to solve it, but I absolutely hate it, and will definitely be coming back to try to clean this one up.
https://github.com/capitalpb/advent_of_code_2023/blob/main/src/solvers/day01.rs