Clojurians Log v2

It works with the default data. Even after spotting some possible edge cases that would cause my code to fail, I’m still very stuck!

You should post under the Day 3 solutions thread, me thinks. Or at least post your code in a thread. Anyway. I had troubles with part 1 too and that was because I failed to find the numbers when they were last on the line. Haven’t read your code super carefully, but just maybe you have the same issue?

It’s not that. Just checked. But, what you said is that should ask for help on the solutions thread?

What I mean is that we try to avoid spoilers in the main channel.

Very easy today, just a simple quadratic equation https://gist.github.com/alexander-yakushev/6ad2ec7bfc16fd9d68c3d133636c59bc "Elapsed time: 0.126625 msecs"

Maybe i had a lucky input? but the brute force worked well for me https://github.com/Ramblurr/advent-of-code/blob/main/src/aoc/2023/day06.clj#L10-L15

Quadratic solver works. I was afraid of floating point accuracy for such big numbers but looks like it's not a case here (my zeros are at: [7711542.749144189, 3.827683025085581E7])

@tsulej IEEE754 has 52 bits for the fraction, input numbers are not that big:)

True, but in reality fractional part in floating point number depends on the exponent. Here we have E7 but for 5.0E15 the next possible number is one larger, ie: (m/ulp 5.0E15) ;; => 1.0

So, above 1.0e16 you have no fractional part at all.

Sometimes AoC tasks go beyond this value.

https://github.com/samcf/advent-of-code/blob/main/2023-06-wait.clj Not as brute force as (range 1 n) but not as fast as binary search or math

@tsulej What's m/ulp? I'm not sure what are you saying with your example.

user=> (long 5.0E15)
5000000000000000
user=> (long 5.0E16)
50000000000000000
user=> (long 5.1E17)
510000000000000000

I think I got it.

(long (double (inc (long 5.0e16)))) => 50000000000000000

https://en.wikipedia.org/wiki/Unit_in_the_last_place is Unit in the last place. It's a measure of a precision of the floating point number. Meaning: what is the difference between next possible double and given double.

(== 1.0e16 (+ 1.0e16 0.5))
;; => true
(== 1.0e16 (+ 1.0e16 1.0))
;; => true
(== 1.0e16 (+ 1.0e16 1.5))
;; => false

I think it is consistent with my point.

user=> (count (Long/toBinaryString 50000000000000000))
56

So as long as the non-fractional part fits into 52 bits, you should be safe.

Yes. But as I mentioned, sometimes you deal with numbers around 1.0e15 and higher in AoC and operations can lead to losing the precision. Race task is not a case fortunately.

Fair enough. Can always switch to BigDecimal if needed.

user=> (inc 5.0e16M)
50000000000000001M

Exactly.

One more example and I shut up 🙂 . There is no representation in doubles for 100000000000000006 which is valid as long.

(long 1.0e17)
;; => 100000000000000000
(long (m/next-double 1.0e17))
;; => 100000000000000016
(long (double 100000000000000006))
;; => 100000000000000000

I coded brute force solutions for day 6 and I was amazed by the speed. About 2 seconds for both parts. 💪

https://github.com/mkrcah/advent-of-code/blob/main/src/day_06.clj with rusty quadratic formula

My solution (based on quadratic formula): https://github.com/genmeblog/advent-of-code/blob/master/src/advent_of_code_2023/day06.clj

quadratic what? 🙂 https://github.com/FelipeCortez/advent-of-code/blob/master/2023/06.clj

I re-used quadratic helper. https://github.com/tschady/advent-of-code/blob/main/src/aoc/2023/d06.clj

Today's puzzle was so much more enjoyable, and I am quite happy that my very simple implementation just worked. Definitely dropped my frustration level with AoC 2023 back down. https://youtu.be/8SMrDhRFr6E

Great. Was able to some more on the challenge. Quadratic indeed. Now it's "Elapsed time: 0.628375 msecs"

Got it by simple binary-search of monotonic function root, in integers, without any quadratic equations, discriminants, square roots etc. Actually easy task, both parts can be solved with a pen & paper without computer at all.

(let [t 44707080N
        d 283113411341491N
        root (fn [t1 t2]
               (let [tc (quot (+ t1 t2) 2)
                     [d1 dc] (map #(- (* % (- t %)) d) [t1 tc])]
                 (cond (= 1 (- t2 t1)) t2
                       (>= (* d1 dc) 0) (recur tc t2)
                       :else (recur t1 tc))))]
    (- (root (quot t 2) t) (root 0 (quot t 2))))

Quadratic equation is 5th grade math, you make it sound complicated:)

Yep, but BS allows to keep in integers, without any mistakes of floats/doubles due to accuracy etc.

By multiplying two longs together you'll get an overflow before a loss of precision from doubles in this task.

Or, actually, "might" get an overflow, not 100% sure

Actually not. Look at N s in numbers literals

That's fair, but similarly BigDecimal can be used for floating-points.

Yep, but when you get f.e. 3.9999999999999 as a root, but you need cell + 1, so is it 3 or 4? Of course, you can check, but integer algorythms avoid of such cases

floor(3.99999999) is 3. It takes a very large number so that the square root of it is a at the margin of error of an integer number. But I get your point.

Nothing more satisfying than brute-forcing 😄 https://github.com/arnaudgeiser/advent-of-code/blob/master/2023/clojure/src/advent_of_code/day6.clj

Here’s day 6 using newtons method:

https://github.com/bhauman/adv2023/blob/main/src/adv2023/day06/sol.clj

only five iterations to solution on my part 2

But I think the simplest solution is to search in steps of 5000 and when you cross over just search the 5000 entries for the cross over point.

5 minutes of simple math saves you 10 minutes of brute forcing 😆 The parsing code ended up being longer than the solution https://github.com/maxrothman/advent-of-code/blob/main/2023/clj2023/src/clj2023/day6.clj

https://gitlab.com/maximoburrito/advent2023/-/blob/main/src/day06/main.clj I made one assumption that I don't have any basis for, but I've learned to accept that in aoc your input is the puzzle, not the problem statement. Solve your input, not the general problem, because often times that's the only way.

https://github.com/rjray/advent-2023-clojure/blob/master/src/advent_of_code/day06.clj A silly mistake on part 1 lead to ~5 minutes of debugging. Part 2 took 3 minutes, total. Regexp for the win 🙂.

Wait - did you just use the brute force solution? And it was fast enough?

Wow - it is! Nicely done @rjray

Brute Force:   "Elapsed time: 9315.748712 msecs"
Binary Search: "Elapsed time: 2.786305 msecs"

Hi, everybody I am a bit of a novice in Clojure (completed a few days from last year's AOC) Just joined your private leaderboard https://github.com/andrewbelo/aoc2023/blob/master/src/day_6_wait_for_it.clj

No regex for me today, I hand wrote my input in - felt good

I almost forgot about the quadratic formula but I’m glad I remembered it existed 😅

finally had time to work on aoc. here's my day 6 solution: https://github.com/rmrt1n/advent-of-code-2023-clj/blob/main/src/aoc/day06.clj