25
๐ - 2025 DAY 3 SOLUTIONS - ๐
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Dec 2025
25 points (100.0% liked)
Advent Of Code
1217 readers
1 users here now
An unofficial home for the advent of code community on programming.dev! Other challenges are also welcome!
Advent of Code is an annual Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.
Everybody Codes is another collection of programming puzzles with seasonal events.
EC 2025
AoC 2025
Solution Threads
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 |
Rules/Guidelines
- Follow the programming.dev instance rules
- Keep all content related to advent of code in some way
- If what youre posting relates to a day, put in brackets the year and then day number in front of the post title (e.g. [2024 Day 10])
- When an event is running, keep solutions in the solution megathread to avoid the community getting spammed with posts
Relevant Communities
Relevant Links
Credits
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
console.log('Hello World')
founded 2 years ago
MODERATORS
Nice! I thought about using numbers but then decided that strings are a lot easier to deal with.
I was curious, so I ran yours and it is only like 3-4ms slower. I was honestly surprised it was that close.
Just goes to show that we're often wrong when estimating and the only real way to know is to benchmark.
Yeah, I vaguely remember reading something about how close string splitting is to all the logarithm math in splitting numbers, and since then I've just always used strings because that's way more intuitive to me lol
My version used strings as well, and I thought that as I was comparing small integers either way, it made sense to stay in ASCII as the strings were already easy to index, and it meant I could skip parsing input numbers, only needing to parse output numbers so they could be summed.
I did start with numbers so I could convert it back to compare, but it's so fast (the whole thing takes 1ms - and that's reading/parsing the input twice) that it's almost a micro benchmark.