This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

## 2021-12-17

## Channels

- # adventofcode (25)
- # announcements (2)
- # babashka (16)
- # babashka-sci-dev (16)
- # beginners (213)
- # calva (15)
- # clj-kondo (126)
- # clj-on-windows (1)
- # cljdoc (5)
- # cljfx (1)
- # cljs-dev (6)
- # clojure (230)
- # clojure-europe (38)
- # clojure-nl (3)
- # clojure-uk (3)
- # conjure (10)
- # core-async (15)
- # cursive (33)
- # fulcro (58)
- # hyperfiddle (4)
- # jobs-discuss (1)
- # kaocha (5)
- # lsp (46)
- # meander (3)
- # off-topic (30)
- # polylith (10)
- # portal (9)
- # re-frame (5)
- # reitit (7)
- # releases (2)
- # ring (17)
- # sci (8)
- # shadow-cljs (6)
- # specter (1)
- # sql (1)
- # testing (9)
- # tools-deps (4)
- # vim (12)

🧵Day 17 Solutions Thread: post your solution here

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 ”

https://gitlab.com/maximoburrito/advent2021/-/commit/324a922979d1de288c777789320c56412916f43a

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

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.

https://github.com/dgtized/advent-of-code/blob/master/2021/day17/trick_shot.clj

@U89SBUQ4T that certainly speeds up my brute-force.

It is slow, but works 🙃 https://github.com/zelark/AoC-2021/blob/main/src/zelark/aoc_2021/day_17.clj

very nice parsing 👍:skin-tone-2:

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

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)

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

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

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

@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.

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

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 😄

https://github.com/kconner/advent-of-code/blob/master/2021/17a.clj, https://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.

@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