13
votes
Day 1: Report Repair
Today's problem description: https://adventofcode.com/2020/day/1
Join the Tildes private leaderboard! You can do that on this page, by entering join code 730956-de85ce0c
.
Please post your solutions in your own top-level comment. Here's a template you can copy-paste into your comment to format it nicely, with the code collapsed by default inside an expandable section with syntax highlighting (you can replace python
with any of the "short names" listed in this page of supported languages):
<details>
<summary>Part 1</summary>
```python
Your code here.
```
</details>
Not my solution, but a fun one from a guy whose blog I follow: I solved Advent of Code 2020, day 1, part 1 in pure AmigaShell. No ARexx! No cheating!
Not sure if he's going to continue trying to do the whole thing (or if it'll even be feasible if the first one runs that slowly), but I thought it was neat.
I won't be winning any speed records since I'm just getting to Day 2 now, but here's my solution for day 1, in Julia. I noticed that I didn't use any loops, so I am going to try to keep doing that since it was a fun challenge. I'll also have everything up in a repo.
Parts 1 and 2
Performance wise, both parts together take 342 milliseconds on the first run, so that includes compilation. Subsequent runs are in the 40-50 millisecond range.
Copied at request of Deimos:
In these early days I usually like to make things more difficult for myself. I'm doing these in Rust.
My solution to Day 1 is generalized to any sum and number of terms:
Day 1
It's extremely slow, and I haven't been able to figure out why yet. If anyone has any ideas, let me know!
I have some bugs/suggestions. I've given hints in case you want to think about them yourself first.
You try some combinations over and over…
because in
main
,recursive_sum
is called in the loop!The program behaviour is the same if all entries are read, then
recursive_sum
is called on the whole list.Parsing stdin fails if you reach the end…
because
Stdin::read_line
returnsOk(0)
at the end of the file!It's more idiomatic to write
The sum is computed repeatedly and needlessly…
because you can keep a running sum at each level of the recursion! That is, you can pass an extra parameter
running_sum
, whererunning_sum == considered.sum()
.The
considered
vector is not necessary…because it is only ever used for
push()
,pop()
,sum()
, andproduct()
! As above, you can keep a running sum and product at each level of recursion, obviating the vector entirely!The base case of the recursion is at
target_num_terms - 1
…but it could be at
target_num_terms
! Then no loop is necessary in the base case.The recursive function could return a value…
namely, the product if one was found. You could represent this as an
Option<i32>
.Extra work is done computing sums that are too large…
because the recursion doesn't stop early if the sum is greater than the target!
You can do even better — if the entries list is sorted, you can stop the loop early once you know that everything else in
remaining_entries
will produce a sum that is too large.I made all those changes in this new version, if you want to compare to what you have:
On my computer, in release mode, this new version can run to depth 5 in under 15 seconds (the target sum needs to be high enough).
This is a fantastic code review. Thank you! I like to think some of these mistakes are due to working in an unfamiliar language, but I also haven't written recursive code since probably last year's AOC :)
Here are my Day One solutions in Python
Part 1
I'm there's a smarter way to do this... lolPart 2
I tried what I thought would be a slightly cleverer way of figuring out the answer... I'm not sure if it is any better. I also re-did part 1 here with the new method.Any feedback is welcome :)
Another late-comer here, I expect to have more time over the weekend but wanted to get a head start on it tonight. Since I'm learning Javascript currently, I'm planning to do the whole AoC event in Javascript. (Functionally, in Node, since I'm creating them as .js files and running them on a CLI, but trying to keep it as vanilla as possible) Here's my Day 1 solution, and my repository is here
Part 1
Part 2
MIT scheme solution
Part 1 & 2
Simple AWK solutions
Part 1
Part 2
that @timer stuff looks really cool I should look into that. I code tons of python for my AI nowadays but my coding interviews usually were always in python.
I knew this type of problem and I tried it using a sort and then going through the array from both ends
Using your timer code it takes 0.386325 milliseconds. And your solution takes about the same amount of time for me
brute_force: 654.206014 milliseconds
better: 4.215089 milliseconds
are you also using a macbook pro 2017?
heres my solution: https://tildes.net/~comp.advent_of_code/to5/day_1_report_repair#comment-5x8u
The built-in
timeit
library is really useful for timing pieces of code as well, including running it many times and averaging it to avoid the possibility of outlier results when you're just timing one call.I'm using Python using Anaconda and Jupyter Notebook. I love Advent of Code because it's a great chance to stretch my coding muscles.
Day 1 A
For this one I just brute forced it. This rechecks several time, both 'A' + 'B' = 2020 and 'B' + 'A' = 2020 show up as valid results. If you wanted to be more efficient, you could make sure that each combination only gets checked once.Day 1 B
This is basically the same as part A, but with an added layer. So instead of checking 'A' + 'B', you're checking 'A' + 'B' + 'C'. This is far, far less efficient because of that added step, but with a data set this small it didn't really matter.Part 1
Part 1
```python def prob_2(input_arr): for i in input_arr: for j in input_arr[1:]: for k in input_arr[2:]: if i+j+k == 2020: return i*j*k ```With Google Sheets. I'm trying to do most of these with one formula, which as of now (day three) has been successful. We'll see what the future holds.
Part 1
Part 2
I haven't really coded anything since the last advent and my lack of improvement shows
Day 1
Bit behind, but I finally got my solution for Day 1!
Part 1 runs in 0.0022 seconds
Part 2 runs in 0.12 seconds
I'm surprised at the lack of Java here
Part 1 - 2.025 ms
Part 2 - 12.69 ms
I thought i was doing the wrong one, didn't realize there were two parts. I'm doing this in C# because it's harder, Python's almost made for this sort of stuff.
Entry 1
Whoops, thanks. The join code is still the same though, right?