Fork me on GitHub
#adventofcode
<
2021-12-17
>
alekszelark04:12:47

🧵Day 17 Solutions Thread: post your solution here

Miķelis Vindavs05:12:17

Classic AoC where part1 makes you feel like you should find a formula to solve it in constant time, but then part2 says “nope, it’s brute force after all simple_smile

😅 2
Miķelis Vindavs06:12:19

the y search space can be reduced to (range (dec y1) (- y1))

norman06:12:20

I hard coded one my bounds experimentally. I am sure I could figure out a more correct solution, but on AoC when you get the answer, it's time to sleep.

3
norman06:12:28

Thanks. I assumed something like that would be correct, but I wasn't sure.

AC06:12:54

@U89SBUQ4T that certainly speeds up my brute-force.

Miķelis Vindavs10:12:14

very nice parsing 👍:skin-tone-2:

nbardiuk14:12:56

thanks, although today we can avoid parsing, just store numbers in a map

thumbnail14:12:30

I like your part1 😅

euccastro15:12:27

Closed form for part1, brute force for part 2 (but part1 gave me confidence about the bounds in the y direction): https://github.com/euccastro/advent-of-code-2021/blob/main/day17.clj

euccastro15:12:58

the insight for part 1 (and for narrowing down the y space) is that after reaching as high as it can, the bullet will fall down to exactly zero height, and the next step must be within the target. if we want to reach as high as we can, the next step after reaching zero height will be at the bottom of the target. (this is assuming that the target is below 0, which is kind of implied in the problem description but I didn't assume in my code; I think I could have assumed that x is always positive too)

euccastro15:12:26

I've cleaned up my code with the assumption (again, kind of implied in the description) that the target is in the bottom right quadrant. it's shorter and prettier now

Antonio Bibiano20:12:23

Was happy to find a solution for part1 but then got super lazy about finishing part 2 :(

genmeblog21:12:46

after some refactoring I ended up with one function which covers both cases and is short (`reductions` is huge helper here). But it was long process... https://github.com/genmeblog/advent-of-code/blob/master/src/advent_of_code_2021/day17.clj

genmeblog21:12:46

@U65FN6WL9 seems to work, however there are gaps in initial x velocities when target is missed. For example for x between 195 and 238 (my case) velocities between 81 and 97 miss the target.

tschady21:12:12

I got a closed form solution (so no boundary checking necessary). 0.1ms, 7ms. writeup: https://github.com/tschady/advent-of-code/blob/main/doc/2021.adoc#aoc-2021-d17

🙌 3
karol21:12:06

https://github.com/kfirmanty/advent-of-code-2021/blob/main/src/day17.clj prior to any refactoring. I had a formula to find possible x-velocities but then for y velocities used the dumbest thing that works i.e minimum velocity is the lowest y of target and upper bound is 1000 which is less than ideal. Will try to optimize it later but I must admit solving AoC while having a flu is much harder than without one 😄

kevinc04:12:21

https://github.com/kconner/advent-of-code/blob/master/2021/17a.cljhttps://github.com/kconner/advent-of-code/blob/master/2021/17b.clj. I got way, way too clever on my first try. I'd rather have to improve a slow naive solution than debug a fast, complex, wrong solution.

euccastro21:12:24

@U1EP3BZ3Q what "seems to work" but doesn't? I didn't do anything clever about x velocities; I just try all the ones that could possibly work

euccastro21:12:17

and even some that couldn't, but no big harm in that since my brute force code runs almost instantly