My https://github.com/wevre/advent-of-code/blob/master/src/advent_of_code/2023/day_24.clj with some notes. I got insight from the posters on reddit who didn’t use numerical solver libraries.

This is the crux of the concept.

Still struggling with part 2. Part 1 required sleeping on it, as I had a problem with detecting intersections in the past. For part 2, I'm trying to understand some code that didn't use a solver package.

https://github.com/rjray/advent-2023-clojure/blob/master/src/advent_of_code/day24.clj Finally got it. A lot of run-time errors related to forgetting to coerce values into bigint, or use big-number versions of arithmetic ops. Pretty sure this was the hardest of the puzzles.

Stuck yesterday with part 2, haven’t seen any solution, hope with the help of @UTFAPNRPT’s notes I can solve it.

still working on the solution slowly. @UTFAPNRPT thanks for the formulas and the idea it works good. Only a bit error I found here it should be c = (xi - xj)/(ur - u)

Here is my solution for part 2. It is based on @UTFAPNRPT one. However, I found a place to improve. Initially it takes ~7 secs to finish, but we can do better. We can find common factors only for one group (it could be any). Then, with probable candidates in hand, we test them against every next group. So the search space narrows pretty fast. With this improvement my solution runs 14 times faster: 0.5 sec. I also added type hints for calculating factors and used pmap. In the end it runs ~60 msecs. One corner case I found in my input is when xj - xi is a prime number. I checked a couple other inputs, they don’t have this property. So I also added some code to deal with it. https://github.com/zelark/AoC/blob/master/src/zelark/aoc_2023/day_24_p2.clj

Finally solved part 2, first time mostly in side app (Libre Office) than Clojure, cause didn't want to implement my own unlinear systems solver (via Simplex or like that) in Clojure. And I need only first four lines of input data for all of the calculations! Taken first 2 rays we have 2 points sliding on them (and 2 variables t1 & t2 determining that points). Then we have a line thru that points (let's call it L). Sitting some time with pen & paper and remembering partial derivatives and trivial calculus & linear algebra we may create a formula for the distance between 2 lines (including all the corner cases - 2 lines in the same plane etc.). So, having this magic formula we may calculate distance between third ray of input data and our L, depending on t1 & t2. And for almost each t2 we may solve equation for finding t1 for making that distance zero = crossing L and third ray of input. But if we take 2 rays - third & fourth, we have only one pair of t1 & t2 which forces crosses both L and third & L and fourth. And once we found t1 & t2 we have p1 & p2 on their rays, and p2 - p1 = directional vector for line L, which is guaranteed (by task description) to cross all the other input rays, so the rest is trivial - in t1 we are at p1 (on first ray), in t2 we are at p2, we do know all the values and need to calculate where we were at t = 0. And we really do not need other input data exept first 4 rays! 😁 Very challenging task!

Very nice.

I eventually solved it (with a huge amount of help from someone who is better at mathematics than I am) by looking at the first three rays and creating a system of nine simultaneous equations. There was no way I was going to solve that system by myself so I then plugged it into SageMath and let it solve it for me. Given that there are a lot more than three hailstones, I guess it's really lucky that they all happen to be arranged in such a way that a single rock can coincide with all of them, because otherwise you'd have a big system of equations with no solutions at all 😕

It's not luck... Wastl spends a good amount of time designing the puzzles and the data for them 🙂.

True, and in this case the instructions in this case do say "While it seems extremely unlikely, if you throw it just right, you should be able to hit every hailstone in a single throw!"

Took me days to solve this in #scittle on my phone’s browser, figuring out the mathematics first, writing the solver for the derived system of linear equations (not as hard as I feared) and then ran into the precision issue. I hoped that emulating Clojure’s builtin fractions would take care of that, but that did nothing to prevent having to deal with 30 decimal digit numbers… Learned about js/BigInt and after switching everything over got the correct result in 24ms.