Clojurians Log v2

Wasted a lot of time on silly misplaced parens error on this one. 😉 https://github.com/jreighley/aoc2019/blob/master/src/aoc/aoc3.clj

Have you tried parinfer or parindent?

I use cursive and parinfer. It was my distance function that added the absolute values of the two vectors. Since it was all on the same line, it didn’t help

(+ (abs x)) (abs y)

(+ (abs x) (abs y))

@erwinrooijakkers nice tip, using peek instead of last shaved 500ms of the 7s.

I'm getting a late start. Are we using the same leaderboard as last year?

(or I could just look at channel topic, I suppose)

I haven’t seen the same style this year @norman

Only made it through part 1 of day 3 while slacking at work towards the end of the day… no one noticed the Clojure instead of Python on my screen 🤷 https://github.com/KennyMonster/aoc_2019/blob/c2dfdfffdc4447c34aa6a7c90b0a763d10da8713/src/day_3.clj

There's some days when I've needed a break to do some real programming and get my brain moving again before going back to 'real work'. So long as it hasn't cut into the hours I'm contracted to bill, anyway. 🙂

Yep

Puzzle 4 was way easier than the last two. I count 8 lines of code for Part 1, with a single line altered to adapt the part 1 solution to part 2.

same here. puzzles are being opened amid of my work time 🤫

Actually, just a single character change for part 2. I have a test for repeated digits that looks like this: (some #(<= 2 (count %)) (partition-by identity (str n)) For part 2, just changing the “<=” to “=” was sufficient.

i used frequency on the list of digits

Still find it awesome how lisps allow you to do things like #((case part 1 <= 2 =) 2 (count %))

@mpcjanssen ?? You mean frequencies? But that doesn’t care about order, so I don’t see how it would detect sequential duplicates differently than non-sequential ones..

@mchampine you are right. it did give the right answer though

Surprising!

no because the digits are increasing

so any same digits are consecutive

Ahh.. got it.

Good call.

rationalisation after the fact 🙂

did not completely think this through before

yes the duplicate check can be pretty dumb if you take advantage of that

I still used dedupe though for part 1

https://github.com/Lokeh/advent-2019/blob/master/day4.org

Wow, using spec. Neat. Btw, you can do a quick and dirty digits conversion with (map read-string (map str (str 123456)))

http://quil.info/sketches/show/4350261fceb6f0e6f385e23fcd9a8ca91623ffd813912ca79c47bfa51ad1a6f1

also nice literal coding with org-babel

the environments are as interesting as the code itself

for mine https://github.com/mpcjanssen/aoc2019/blob/master/day04.ipynb

Yes, tried org-babel a while back. Pretty great stuff you can do. I was mixing bash, python, clojure, and LaTeX as I recall.

Todays one went pretty smooth https://gitlab.com/dmarjenburgh/adventofcode/blob/master/src/adventofcode/year_2019.clj#L65-78

apart from the somewhat vague description for puzzle #2, today was quick & easy: https://github.com/skazhy/advent/blob/master/src/advent/2019/day4.clj

here’s mine https://gist.github.com/roman01la/c607849e71e6de11549976428cd3d6a6

@karlis indeed, it took me a while to decypher description of the 2nd part

neat use of frequencies! That's a method I only seem to use during advent of code 😄

Oh, this is so great solution. Clever. I overcomplicated a thing this time.

Smart regex for increasing

Try a first time with "filter wrong values", but my predicates were pretty bad, so my evaluation "never" finishes. I re-write it in a dirty (but successful) way. https://github.com/Charlynux/advent-of-code-2019/blob/master/day04/day04.clj

regex turned out to be much faster than parsing and comparing digits

I think each year there are a few problems like day 4 pt. 2 that seem almost intentionally vague… https://github.com/taylorwood/advent-of-code/blob/master/src/advent_of_code/2019/4.clj

I did (= (seq s) (sort-by identity compare s))) 10 times slower than regex

Mine is ugly, but it works: https://github.com/rhinoman/aoc2019/blob/master/src/aoc2019/day4.clj

@taylor nice digits func to convert an int to a seq of digits without string manipulations. I would have never thought to do it that way

@jrwdunham my solution initially used string manipulation, I got about 10x speedup when I cut out all of the type conversions 🙂

bug in num-to-digits for 0.

user=> (num-to-digits 0)
[]

(time
  (let [MIN      382345
        MAX      843167
        int-vec  (fn [n] (->> n str (map str) (mapv #(Integer/parseInt % 10))))
        low      (int-vec MIN)
        high     (int-vec MAX)
        too-low  #(neg? (compare % low))
        in-range #(neg? (compare % high))
        pwds     (for [a (range 0 10)
                       b (range a 10)
                       c (range b 10)
                       d (range c 10)
                       e (range d 10)
                       f (range e 10)
                       :let [n [a b c d e f]]
                       :when (->> n frequencies vals (some #{2}))]
                   n)]
       (->> pwds
         (drop-while too-low)
         (take-while in-range)
         (count))))
"Elapsed time: 13.145288 msecs"
=> 290

:troll:

James'es times on my input and laptop are: "Elapsed time: 159.510294 msecs" "Elapsed time: 324.308817 msecs"

roman's times: "Elapsed time: 227.731395 msecs" "Elapsed time: 172.91049 msecs"

Day 4 part 2 was written very poorly.

very cool. using for like that to avoid the intermediate numbers

Not too fond of the 10 mins wait after submitting x number of wrong answers

btw, I understood part 2 immediately by looking at examples, don't know why so many were confused. (however, there were few similar requirements in previous years' puzzles, so I might have just recognized it)

same here. although I tend to jam the examples into my tests before I think too much over the problem description

I thought I did too until my answers were wrong

222222 should or shouldn't be valid?

shouldn't

maybe you're unlucky and got input data with an extra edge case

repeating 2 and its not apart of a larger group

its the only group

oh no, now I'm confused. it should be

there must exist at least one consecutive group with a length of 2+

also this is why I did not use frequencies initially, because I recalled "2 but not 3+ in a row", and thought of letters, and did not figure out that there can only be 1 streak per digit, and can't be e.g. 11xx1x.

I think it should not, because it is more than 2 in a row

^ this is part 1. part 2 is exactly 2 instead of 2+

@regen "at least one 2+" for part1, "at least one exactly 2" for part 2

Should 123455 work?

yes, for both

*unless outside the range

But isn't the 55 part a larger group of repeating?

group is just same digit several times in a row

same reason 123444 didn't count

444 is a group of 3: three 4 s in a row

consecutively

(partition-by identity coll) gives you groups : (partition-by identity "123444") => ((\1) (\2) (\3) (\4 \4 \4))

Thats not how I understood it. Which was my complaint since it was left up to interpretation

I figured 333444 should work

since the 33 or 44 are not part of a larger group

but you are making the case that it wont work since they are both groups of 3

group of 2 is two of the same digits in a row. larger group is tree or more of the same digit in a row

I am, yes. 333444 should be invalid

because it has 2 groups of size 3 each,

the two adjacent matching digits are not part of a larger group of matching digits.I understood this as: As long the repeating digit is not part of the largest group of all groups then it is valid.

So 122333 is valid and so would 222333

but not 123444 since the repeating digit is part of the larger group

yes. here, 33____ and 33__ are two adjacent matching digits but both are part of a larger group of matching digits 333___

same for 44_ and _44 in 444

It doesn't like it when the first digit is 0

122333 is valid because has 22.

222333 has two groups. Each of size 3 meaning there is no larger group. Since they are both the same

122333 is valid, because there is only 2 2 in a row, 222333 in invalid, because there is 3 2 in a row

No, there are two larger groups.

. (map count (partition-by identity "122333")) => (1 2 3) ;; has group of exactly 2 numbers (map count (partition-by identity "222333")) => (3 3) ;; does not have group of exactly 2 numbers

There we go. They should have just written that ^

> does not have group of exactly 2 numbers

this is why people here bragged about "part 2 was just 1 char diff commit!": (->> ... (some #(<= 2 %))) for part 1 and (->> ... (some #(= 2 %))) for part 2

Not for me. I kept thinking "Oh I get it now." Type the answer in and getting "Sorry wrong answer. Plz wait 10 mins before submitting again."

But wasn't going to bed until I got the goldie

first part was easy though

happened a lot to me in other puzzles. It is not in the aoc interests to make it obvious to you what needs to be done, hence lots of text, indirection in terminology, random bold font highlights, "by the ways", ambiguous examples

I wrote a crazy regex to get dec4/pt2 which i'm sharing for laughs. (Liking the concise and sane strategies I'm seeing here):

(def pattern
  (re-pattern
   (str
    "("
    "(^|[^1])11($|[^1])"
    "|"
    "(^|[^2])22($|[^2])"
    "|"
    "(^|[^3])33($|[^3])"
    "|"
    "(^|[^4])44($|[^4])"
    "|"
    "(^|[^5])55($|[^5])"
    "|"
    "(^|[^6])66($|[^6])"
    "|"
    "(^|[^7])77($|[^7])"
    "|"
    "(^|[^8])88($|[^8])"
    "|"
    "(^|[^9])99($|[^9])"
    "|"
    "(^|[^0])00($|[^0])"
    ")")))

zeroes are invalid here :opieop:

right. still works though.

because you filter them out earlier/later

filter them out earlier, with yet another regex

(filter (fn [d] (re-find #"(.)\1" d)))

oh, nevermind, that doesn't do it...

I'd like to see concise pattern including all of it: range, group size, ascendingness

https://github.com/Average-user/adventofcode-clj-2019/blob/master/src/adventofcode_clj_2019/day04.clj

@misha I did a similar optimization to only iterate through non-decreasing digit-vectors 🙂

(defn incr [ds]
  (let [d (peek ds)]
    (if (= 9 d) ;; recursive
      (let [ds* (incr (pop ds))]
        (conj ds* (peek ds*))) ;; roll over using prev digit
      (conj (pop ds) (inc d)))))

(iterate incr [1 4 6 8])
;; => ([1 4 6 8]
;;     [1 4 6 9]
;;     [1 4 7 7]
;;     [1 4 7 8]
;;     [1 4 7 9]
;;     [1 4 8 8]
;;     [1 4 8 9]
;;     [1 4 9 9]
;;     [1 5 5 5]
;;     [1 5 5 6]
;;     ...)

https://github.com/jrwdunham/aoc2019/blob/master/src/dec04/core.clj

yeah, but anything in user space is likely to be slower than for :opieop:

slower and less readable :kappa:

@misha my un-aptly named monotonically-increasing? filter seems to be correctly filtering out the 0s

I pointed that out so you could speed up regex

I replaced the nested for clauses in your solution with (for [n (iterate incr [0 0 0 0 0 0]]) and got a 13.5 msec => 9.0 msec speed up

i see. See any way to make the regex more concise, with backreferences and lookahead/behind fanciness?

not even gonna try :d:

haha.

Yes, also not fast: part 1: Elapsed time: 485.806268 msecs; part 2: Elapsed time: 578.42914 msecs.

what is incr? inc?

the recursive function I posted above

(not great at naming things)

taking out the 0s disjunct in the regex speeds things up by 50-100ms

is it consistent speed up? do you consistently get 13ms on my snippet? for me it fluctuates +-2ms

or did you just compare 9ms on your machine to 13 on mine? :troll: different code too!

For speed AND idiomatic code it's probably better to do it in Rust

Both on my machine with the same inputs

for is idiomatic :)

nice

Yep, i didn't thought about using for. But my solution is more general (not only for six digit length numbers)

And is only slightly slower

of course! hence the trollface in my snippet )

got it down to 3.6 ms using transducers 🙂 (measured using Criterium's quick-bench)

(defn day4
  [start end part]
  (let [dv     (fn [n] (mapv #(Character/getNumericValue %) (str n)))
        dv<    (fn [a b] (= -1 (compare a b)))
        startv (dv start)
        endv   (dv end)
        incr   (fn [ds] ;; increase digit vector until it satisfies non-decreasing condition
                 (let [d (peek ds)]
                   (if (= d 9) ;; recursive
                     (let [ds* (incr (pop ds))]
                       (conj ds* (peek ds*))) ;; roll over using prev digit
                     (conj (pop ds) (inc d)))))
        pw?    (fn [xs]
                 (some #((case part 1 <=, 2 =) 2 (count %))
                   (partition-by identity xs)))]
    (transduce
      (comp
        (drop-while #(dv< % startv))
        (take-while #(dv< % endv))
        (filter pw?))
      (completing (fn [n _] (inc n)))
      0
      (iterate incr (vec (repeat (count startv) (first startv)))))))

(day4 124075 580769 1) ;; => 2150
(day4 124075 580769 2) ;; => 1462

wow nice!

Nice @qythium, about 1msec faster than @dmarjenburgh’s solution in my timing.

the only other place I’ve ever used this is in coding interviews :lol:

I had a solution that worked for all the examples but not for my test input; took me like 6 submissions to get it right

Doing AOC last year was so much easier when I was on vacation for almost the entire month. I have a feeling I'm going to be playing catch up all month...

Yeah, I may need to curb my participation for a while. Too busy.

But I feel better about it knowing that I'm not aiming for leaderboard points. I'll learn what I'm aiming to, just more slowly.

I always feel like I am cheating when I use regex. That never stops me from being tempted. (Including today)

Simple enough: https://github.com/jreighley/aoc2019/blob/master/src/aoc/aoc4.clj It’s not too often that I use ns without a :require. The separated-pairs? fn seems a bit hacky, but effective.