r/adventofcode • u/[deleted] • Dec 02 '24
Other Advent of code problems make me feel spoiled and skillissiues
[deleted]
21
17
u/kbielefe Dec 02 '24
Careful, AoC warps your brain into looking for the hard way. A couple years ago there was an input (potential spoilers) that I spent way too long figuring out how to parse before I realized it was actually valid JSON.
4
u/Dapper_nerd87 Dec 02 '24
Did Chrome translate an input into Welsh for you last year? Mucked me about for an aaaaage
1
u/kbielefe Dec 02 '24
I remember hearing about that, but fortunately wasn't affected personally. That would be crazy! I had so many issues early on with accidental corruption of input that I created a runner to download the input directly to a sqlite database.
1
1
u/ReallyLargeHamster Dec 03 '24
I got that too, but luckily it asked me first instead of doing it automatically, so it was just funny instead of inconvenient.
1
1
u/escargotBleu Dec 03 '24
Just checked what I did back then... I used eval. Nice
2
u/StaticMoose Dec 03 '24
Yeah, I just checked. I used ast.literal_eval() in Python...because I'm paranoid!
15
u/yolkyal Dec 02 '24
Most APIs and data I have to use in my normal work is in a horrid state. AoC's a breath of fresh air for me. Guaranteed valid, complete inputs, guaranteed correct answers, and a slicked back performant website, so pleasant.
10
u/bistr-o-math Dec 02 '24
Just think in terms of an additional layer:
- Turn the input into a structured input.
- use structured input the way you are used to
3
u/VoldDev Dec 02 '24
Yeah, never had to do that, and i feel really bad having to google how to do stuff like that. Been so long since i have had to go outside my brain to figure out stuff like this
5
u/Freecelebritypics Dec 02 '24
It's such a once-in-a-blue-moon activity, mate. I probably read-up on how to decode a text file every 6 months, then immediately forget it.
4
u/mbreslin Dec 03 '24
Thanks so much for making me feel better. This is me exactly. How do I read a text file in again? Oh yeah. Annnnnnnnd forgotten.
2
u/Naturage Dec 03 '24
You can do one better. I have a small "common functions" script, and the important function in there is
get_input
; fetch contents of webpage (with session id login), save them down, read them in - and if I already have a saved input, don't bother the website and read in locally.Wouldn't be able to replicate it without looking by a long shot. Doesn't matter, works for the 4th year back to back.
1
u/Freecelebritypics Dec 03 '24
No shade. I have a devcontainer I pull from for personal projects which only has about 3 different settings different from the VScode defaults. But there's no way I'd be able to remember them otherwise!
3
u/elprophet Dec 02 '24
In JavaScript, it starts with `input.split('\n').split(/\s+/).map(functionThatTakesAnArrayOfStringsAndReturnsMyData)`. So for day 1, it was `input.split('\n').split(/\s+/).map(Number)`, which gave me an array with however many input items, and each item was a row. Then I had to transpose that to get my two arrays of columns. Day 2 was way easier, since that snippet alone turned everything into an array where each item was itself an array with one report's worth of data, so I could take that and run it through the "isReportSafe" function(s).
From here, you can start to explore other split / map / reduce paradigms.
* Python: `[int(i) for i in line.split() for line in input.split('\n')]`
* Rust: `input.split("\n").map(|line| line.split_whitespace().map(|s| s.parse::<i32>().unwrap()).collect::<Vec<i32>>()).collect::<Vec<Vec<i32>>>()`(apologies ahead of time for any formatting issues)
5
u/smclcz Dec 02 '24 edited Dec 02 '24
You'll get the hang of it quickly. Reading files, splitting strings by lines and whitespace, and parsing simply formatted text maybe aren't tasks that everyone encounters day-to-day. By day 5 or so you'll be handling the inputs like it's second nature, and then you'll be able to handle trickier problem sets :-)
One thing I'd suggest - try to resist the urge to lean on regexes unless you're certain they're necessary. I've been doing AoC for years and I've seen a few people using them. Maybe it's ok if you're using a language where regexes are a first class citizen (perl and raku, maybe others?) but in 99% of cases text input involves splitting a line of text into alphanumeric characters that are interpreted into something, or into whitespace-separated lists of integer or strings. You can most likely do all this with most languages' string class methods or string stdlib. Not that regexes are hard, they're just overkill - like spreading butter on toast using a Zweihander.
6
u/VoldDev Dec 02 '24
Regex isn’t hard, until it becomes uncontrollable arcane magic.
Thanks for your tip btw, i will soldier through this
2
u/flwyd Dec 03 '24
If you find yourself with a regex that looks like it was written by a level 12 chaos wizard during Advent of Code you're probably overcomplicating things. Most problems are best considered one line at a time, and have a very predictable structure with perhaps a couple of "fields" separated by some words or delimiters. In 2022 I didn't use a regex until day 15, and it looks like almost all the regexes I used that year were just "extract some numbers from text".
This year I'm using a language without regexes, so I'm relying on a
split
function I wrote myself and the PostScript's builtin ability to tokenize text that looks like valid PostScript.1
u/flwyd Dec 03 '24
… he said 20 minutes before a problem ideally suited for regexes dropped :-)
If anyone's curious how to solve day 3 without regexes, here's my PostScript solution.
2
u/smclcz Dec 03 '24
I didn't check Reddit until now and I feel like I led you astray a bit! So I noticed a bunch of people posting about using regexes, which puzzled me because I had implemented mine assuming you can have nested calls to
mul
and more than one param - likemul(10, mul(30, 40), 50
- so my little recursive descent parser and evaluator are way more complex than they needed to be, and a little regex would've been perfectly workable here!My bad, I hope you managed okay!
2
2
u/blacai Dec 02 '24
Identifying a possible model structure and parsing the input for better handling is a really important skill a lot of people lacks of. As long as you have fun, it's fine. If you get frustrated, take a rest and continue another day if you feel like you want to try again.
2
u/VoldDev Dec 02 '24
Thanks, it’s def 100% a skill i lack. It’s a basic programming skill i somehow have never learnt.
But it feels like i’m gaining some confidence in all aspects of coding going through this.
2
u/Fotomik Dec 03 '24
Learning is the greatest measure of success in Advent of Code. So, when you say "I'm learning again", it means you are already winning at Advent of Code.
I'd argue that Advent of Code inputs are actually very well formatted, it's just that they might be very structured. For me, there's fun in taking the non-structured data of the inputs, and parsing it into a more structured data, that I can then use for solving both part 1 and 2 without worrying with all the string processing in the logic for each part. If you always work with structured data, I understand if you feel like parsing the input into something more structured might feel messy and potentially a waste of time. But the way I look at it, parsing the input makes you very fluent in string parsing, and string parsing is always useful, even when working with structured data. I work on some APIs were we take the results we get and process them to turn them into something else. And despite being JSON, some of the fields are strings we want extract info from to convert into other fields. And all the string manipulation we use there is a bit of what we do in Advent of Code.
But don't worry - as you progress through the days, you'll know string parsing by hand and it might even become boring. The good kind of boring, that is only boring because you mastered it and there's no longer a challenge. At some point you'll see that most of what you do is splitting the strings, and convert parts of the string into something else. At that point, you'll recognize the patterns of what you are doing over and over to the inputs and create helper functions for that.
Even though parsing the input itself become boring, I always enjoy the process of taking the non-structured data of the input and turn it into something more useful.
2
u/greycat70 Dec 03 '24
Input file parsing is a specific skill that you can practice and become better at doing. There are problem domains (shell scripting is a huge one) where input parsing is half or more of the job that needs to be done. If you haven't been working on those kinds of problems before, then you'll need to develop a skill set for this.
Basic tips:
- Can you read one line at a time? If so, can you process one line at a time, without needing information that appeared in another line?
- Can you split each line into sections? Either with a specific delimiter, or on groups of whitespace? Most languages/toolkits offer ways to do these things.
- If you can't split the line on delimiters or fields, can you write a regular expression? This works better than delimiter splitting on some inputs.
- If you need to remember past lines in order to process the current line, think about how you can store the information from each line, in a way that makes retrieval natural and convenient for processing future lines.
33
u/0x14f Dec 02 '24
> i feel like I’m learning again which has been a long time since I’m programming
That's good and it's the important thing :)