I used Rust and match_indices to get the answer.
Advent of Code 2023 is nigh
191–200 of 319 posts
Re: Advent of Code 2023 is nigh
#192I don't know if I'll even bother this year. Their puzzles start feeling like chores by the 10th problem or so and I drop out. Maybe I'll learn a new language to spice it up this year.
I'm using this year's to dust off my Rust skills in advance of a new job using that language, so that's nice too.
Re: Advent of Code 2023 is nigh
#193Without going into spoilers, its interesting that people jumped to regex to solve this. For me that was a fairly non intuitive when I first saw the problem(both parts). What jumped to me is the problem statement indicated a finite number of states and I crafted a solution based on that information. But its really cool to see how we all jump to different implementations.
In the end, I figured out a manual way around that, but then afterwards I realised that the iteration isn't really necessary given the problem at hand, and ended up going a completely different route that was a lot faster.
What surprised me is that I'd thought of the alternative at the start while reading the description, and then dismissed it because iteration is typically so convenient for these sorts of things.
Re: Advent of Code 2023 is nigh
#194I've never done AoC before. It seems like the success criteria is primarily about getting the correct answer, and secondarily about submitting a solution as quickly as possible if you want to be on the leaderboard. Is that right? Is there any centralized place for seeing other people's solutions? I'd like to be able to learn from how others approach the problem, and what more elegant or performant solutions exist tha…
The the success criteria is whatever you want it to be.
* Learn a new language
* Practice a language you already know
* Try to solve things in a small number of lines
* Try to solve things where the solutions run as fast as possible
* ... any number of other personal goals
* Try to make the leaderboard
I've been solving the older years and learning rust in the process. I made it a secondary goal that all 49 solutions should be able to run in under 1s total. 2015 was easy, 2016 less so.Re: Advent of Code 2023 is nigh
#195Earlier quoted context omitted.
I also started to write a finite state machine for part 2 but found it too tedious to craft by hand. How did you do it?
Not OP, but I too first thought of a state machine. As soon as I started to write it I realized I was over-solving a day-1 problem. So I switched to brute force https://pastebin.com/r1jNCSdm Once I get a line back from that, it's the same problem as part A.
Abstractly I do this:
read_file()
lines = read_lines()
sum = 0
while lines:
left = get_first_num_forwards(line)
right = get_first_num_backwards(line)
sum += integer(left+right)
return sum
I define get_first_num() something like this: get_first_num(line):
lowest_index_pair = None
for key,val in dict.values():
get_index_of_key_if_exists()
if_exists: update_lowest_index_pair()
index,num find_first_instance_num() //just gets the first num that appears
update_lowest_index_pair()
return lowest_index_pair[1]//just returns the number
Basically the idea is very similar to yours. We parse each line 11 times in both direction(10 per the word_vals dict and once more to find the index of the first numerical) which is only 22 parses. Then we grab the minimum index from this list and concat with the opposite side.I just don't do any replacements at the cost of a longer run time. But I figure the cost of 11 parses was low enough that it wouldnt impact the run time significantly for this exercise.
The key point is that overlaps are not an issue because we check for string comparisons in the methods
Re: Advent of Code 2023 is nigh
#196Earlier quoted context omitted.
Warning: post contains spoilers, HN doesn't support spoiler text so continue reading at your peril. These edge cases are triggered by fundamentally approaching the problem incorrectly. In some ways it's excellent to bring that up early in a way that's relatively easy to debug and diagnose. Like many others I started with the wrong solution, and I was hit by the same problematic cases, but what I found interesting was…
Further spoiler: I replaced "one" with "o1e", "two" with "t2o", etc. which is hacky as hell, but works for throwaway contest code. (Replacing as suggested above also works, but is more typing.) That let me keep the problem in the filter/map/first-last/reduce space, which was the shape of my solution to part 1.
impl fully showing the trick: https://github.com/rileymichael/aoc-2023/blob/master/src/mai...
Re: Advent of Code 2023 is nigh
#197Earlier quoted context omitted.
I heard the question was difficult before solving it, and then I was surprised when I didn't hit any speed bumps. The overlapping case didn't even occur to me. It turns out I stumbled upon a simple solution: use two regexes. One to match the first digit, and one to match the last. Then the overlapping is a total non-issue.
If the whole numeric part of the string was something like "eightwo", I think that solution would fail.
Re: Advent of Code 2023 is nigh
#198two1nine eightwothree abcone2threexyz xtwone3four 4nineeightseven2 zoneight234 7pqrstsixteen eighthree sevenine oneight xtwone3four three7one7 eightwothree oooneeone eight7eight
Re: Advent of Code 2023 is nigh
#199Earlier quoted context omitted.
So are you saying that overlapped characters can be used for both numbers? Meaning: - eightwothree -> 823 (answer 83) - 4nineeightseven2 -> 49872 (answer 42) - zoneight234 -> z18234 (answer 14) I interpreted the instructions as saying to take the first match from the left and not count the overlaps. Unfortunately this gives the same answer as the overlap interpretation on the examples given in the problem statement:…
It could have been more clear. The wording from the problem is "the last digit on each line". To me, that pretty clearly implies "the rightmost substring containing a digit", but I guess I can see how someone could question that interpretation.
Re: Advent of Code 2023 is nigh
#200Earlier quoted context omitted.
Not OP, but I too first thought of a state machine. As soon as I started to write it I realized I was over-solving a day-1 problem. So I switched to brute force https://pastebin.com/r1jNCSdm Once I get a line back from that, it's the same problem as part A.
Sorry all, I misused the word finite state. I meant it more from a combinatorics viewpoint(e.g. we only have X amount of operations per Y interval). You could consider my solution to be brute force code. Abstractly I do this: read_file() lines = read_lines() sum = 0 while lines: left = get_first_num_forwards(line) right = get_first_num_backwards(line) sum += integer(left+right) return sum I define get_first_num() som…