Fork me on GitHub
#adventofcode
<
2017-12-21
>
fellshard08:12:24

Fun with List Processing

ihabunek14:12:17

well i have a bug 😄

ihabunek14:12:23

can't trace it for a while now

fellshard16:12:16

I need to remember to use flatten more often...

borkdude16:12:38

I’m still in progress, so not looking, but I’ve already used flattened. I thought I could avoid assembling the whole grid from the parts, but then realized 3x4 is divisble by 2, sigh… 🙂

ihabunek16:12:48

i found the bug, it was due to not reading the question properly

ihabunek16:12:28

trash performance

bhauman17:12:29

@ihabunek just a tip. for is pretty darn powerful for comprehensions you can do (for [x (range 10) y (range x)] [x y])

ihabunek17:12:14

i know but i wanted nested lists so i nested fors

bhauman17:12:32

darn well that makes sense

ihabunek17:12:58

but i'm sure much of my code can be written in a nicer way

ihabunek17:12:12

i'm still learning new functions every day

bhauman17:12:34

@ihabunek I would call distinct on variants before using it

bhauman17:12:02

as "##/##" only has one variant

bhauman17:12:34

unless of course I'm missing something again

ihabunek17:12:04

It's lazy though so distinct would make the whole thing eval and slow it down.

ihabunek17:12:40

I think. 😀

bhauman17:12:42

distinct is lazy 🙂

bhauman17:12:00

I was just looking for what was slowing you down

bhauman17:12:54

i don't think that's going to help much

mfikes17:12:01

Very clean solution @bhauman

bhauman17:12:40

@mfikes our solutions are practically identical

mfikes17:12:29

Yes, I started thinking that when I saw (concat rotations (map flip rotations))

bhauman17:12:21

your split-xf function is different from my break-into which is interesting

bhauman17:12:51

oh it doesn't matter if they are rotated/transposed at this point

bhauman17:12:15

I was maintaining fidelity when I didn't have to

bhauman17:12:07

I definitely really like how you are composing everything into one big transducer function

mfikes17:12:39

Yeah, I don't think I succeeded completely. Or, at least I can say, Planck still consumes a few GB when solving it.

bhauman17:12:51

now I get it, I really like your split-xf approach

mfikes17:12:07

Dunno if this is just lazy cleanup of garbage or if it is true head-holding type stuff.

bhauman17:12:09

way more straight forward

bhauman17:12:05

I would guess its the garbage

mfikes18:12:59

I’m curious if there is any self-referential pattern for part 2 that would allow you to avoid brute force. (I haven’t bothered to check.)

bhauman19:12:00

discussion HINT

bhauman19:12:00

discussion HINT

bhauman19:12:30

since depth isn't a problem a recursive solution seems like it could perform well

bhauman19:12:59

because we don't have to transform back to the original and if done right we could memoize whole portions of the tree

bhauman19:12:22

and the return type is just a string or a number

borkdude20:12:17

Sorry, I hijacked your discussion… I’ll remove

bhauman20:12:09

no worries

bhauman21:12:00

holy crap the memoized recursive solution runs in 5ms

bhauman21:12:24

the recursive solution has to bridge past the divisible by 2 divisible by 3 ambiguity

borkdude20:12:58

I tried an answer that I seriously computed, but then it said: this is the answer for someone else. LOL

borkdude21:12:08

but one bug I had: I didn’t consider ordering of the rules. Obviously that’s important

ihabunek21:12:49

cheater! 😄

ihabunek21:12:54

i had that the other day too

ihabunek21:12:06

the one with two parallel programs

ihabunek21:12:21

i gave the answer for the wrong program

bhauman21:12:43

I now have a 5ms solution for part 2

borkdude21:12:38

DOH, I thought for rotate, rotating the outer nodes of the square around the center one.. what was I thinking, looool

mfikes21:12:02

Oooh. Does the rule order matter? I didn't incorporate that into my solution.

borkdude21:12:28

I thought it was my mistake, but now I realize my rotations are totally bogus

borkdude21:12:05

surprise it did work for the example

mfikes21:12:43

My rotations were wrong initially as well and my code worked for the example

bhauman21:12:02

the logic order (mod 2) comes before (mod 3)

mfikes21:12:22

Yes, that order is crucial for, say 6 or 12

borkdude21:12:30

yeah, got that

borkdude21:12:46

I’m creating an extended rule book that already includes the rotations/flips

borkdude21:12:51

so you can just lookup by whatever you have

borkdude21:12:00

but then you have to take care of the order

bhauman21:12:00

yeah thats what we did

bhauman21:12:12

I don't think so

borkdude21:12:24

ok well I thought it was my mistake that there would be some rotation literally in the rule book and I would be overriding it

bhauman22:12:31

just make sure your (count (distinct (vals rules)) is equal to the original rulles length

borkdude22:12:52

yeah, added an assertion for that. I’m using more assertions since you helped me out 🙂

borkdude22:12:51

Phew, part 1 solved now.

borkdude22:12:49

Part 2 also.

borkdude22:12:11

My assumption was that the rules could not be orthogonal with respect to rotations. E.g. if there would be a rule A => that had rotations A’, A’‘, but there would also be a rule B =&gt; , with B equal to A’ sorting the rules like A, B, A’ would mess things up

borkdude22:12:33

But maybe they were orthogonal or however you may put this