Nice :D
How's the speed now?
Counting the number of corners was a very useful hint for part 2. I had the most trouble with detecting the double corners, i.e. like in the example where the two B fields touch diagonally:
AAAAAA
AAABBA
AAABBA
ABBAAA
ABBAAA
AAAAAA
Still, I would've taken a lot longer and probably made really-bad-performance-code without reading this :D
I found multidimensional markers for partition to work really well for finding the fields: Areas ← ⊜□:⇡△.+1⍜♭⊛
It just groups the other array's contents according to adjacent markers, horizontally and vertically. Took me quite a bit to figure out what's actually happening in the example in the documentation ^^'
I spent a while thinking about how to best do a flood fill in Uiua when I saw that ⊜ (partition) works beautifully with multidimensional markers: "Groups are formed from markers that are adjacent along any axis.", meaning I just had to convert all letters into numbers and I'd get all indices belonging to a field into an array.
For part 2, I cheated a bit by coming here and reading that you only need to count the edges. To my surprise, the second part is actually a bit faster than part 1. Takes less than 0.2 seconds each though :D
Run with example input here
$ RRRRIICCFF
$ RRRRIICCCF
$ VVRRRCCFFF
$ VVRCCCJFFF
$ VVVVCJJCFE
$ VVIVCCJJEE
$ VVIIICJJEE
$ MIIIIIJJEE
$ MIIISIJEEE
$ MMMISSJEEE
.
N ← +[0_¯1 0_1 ¯1_0 1_0]
Areas ← ⊜□:⇡△.+1⍜♭⊛
Peri ← -/+≡(/+∊N¤)⟜¤⟜(×4⧻)
Sides ← (
⊙(-¤)↯:▽⊙0×°⊟.+2⌵⊸-+1⊃⊣⊢⊸⍜⍉≡⍆
⧻⊚⊸∊1_3⧈(/+/+)2_2.⍜⊡=₀+1:
+⊙(×2/+/+⧈(∊[[1_0 0_1][0_1 1_0]])2_2◌)
)
Cost! ← /+≡◇(×^0⟜⧻)
PartOne ← (
# &rs ∞ &fo "input-12.txt"
⊜∘≠@\n.
Cost!Peri Areas
)
PartTwo ← (
# &rs ∞ &fo "input-12.txt"
⊜∘≠@\n.
Cost!Sides Areas
)
&p "Day 12:"
&pf "Part 1: "
&p PartOne
&pf "Part 2: "
&p PartTwo
After finally deciding to put aside Day 9 Part 2 for now, this was really easy actually. The longest was figuring out how many extra dimensions I had to give some arrays and where to remove those again (and how). Then part 2 came along and all I had to do was remove a single character (not removing duplicates when landing on the same field by going different ways from the same starting point). Basically, everything in the parentheses of the Trails! macro was my solution for part 1, just that the ^0 was ◴ (deduplicate). Once that was removed, the solution for part 2 was there as well.
Run with example input here
Note: in order to use the code here for the actual input, you have to replace =₈ with =₅₀ because I was too lazy to make it work with variable array sizes this time.
$ 89010123
$ 78121874
$ 87430965
$ 96549874
$ 45678903
$ 32019012
$ 01329801
$ 10456732
.
Adj ← ¤[0_¯1 0_1 ¯1_0 1_0]
Trails! ← (
⊚=0.
⊙¤
≡(□¤)
1
⍥(⊙(≡(□^0/⊂≡(+¤)⊙¤°□)⊙Adj
≡(□▽¬≡/++⊃=₋₁=₈.°□))
+1⟜⊸⍚(▽=⊙(:⟜⊡))
)9
⊙◌◌
⧻/◇⊂
)
PartOne ← (
# &rs ∞ &fo "input-10.txt"
⊜∵⋕≠@\n.
Trails!◴
)
PartTwo ← (
# &rs ∞ &fo "input-10.txt"
⊜∵⋕≠@\n.
Trails!∘
)
&p "Day 10:"
&pf "Part 1: "
&p PartOne
&pf "Part 2: "
&p PartTwo
Adapting the part one solution for part two took me longer than part one did today, but I didn't want to change much anymore.
I even got scolded by the interpreter to split the evaluating line onto multiple ones because it got too long.
Can't say it's pretty but it does it's job ^^'
Run with example input here
PartOne ← (
&rs ∞ &fo "input-8.txt"
⟜(▽¬∈".\n".◴)
⊜∘≠@\n.
:¤⟜(:¤-1△)
≡(□⊚⌕)
◴/◇⊂⍚(≡(-:⟜-°⊟)⧅≠2)
⧻▽¬:⊙(/+⍉+)⟜⊓><,0
)
PartTwo ← (
&rs ∞ &fo "input-8.txt"
⟜(▽¬∈".\n".◴⟜¤
▽:⟜≡(>1⧻⊚⌕)
)
⊜∘≠@\n.
:¤⟜(:¤-1△)
≡(□⊚⌕)
⊸⍚(
⧅≠2⊙¤
≡(:¤⟜-°⊟
⍢(⊙⊂⟜-⊙⊸⊢
| ⋅(=0/++⊓><,0⊢))
□⊙◌◌
)
)
◴/◇⊂/◇⊂
⧻▽¬:⊙(/+⍉+)⟜⊓><,0
)
&p "Day 8:"
&pf "Part 1: "
&p PartOne
&pf "Part 2: "
&p PartTwo
A solution in malbolge would be amazing and also kinda terrifying
Glad to hear that my attempts at de-spaghettifying worked to some degree at least :D
I don't remember exactly what this difference caused but I do remember it being very annoying to debug.
Edit: the language used is Uiua
Thanks to your solution I learned more about how to use reduce :D
My solution did work for the example input but not for the actual one. When I went here and saw this tiny code block and you saying
This turned out to be reasonably easy
I was quite taken aback. And it's so much better performance-wise too :D (well, until part 2 comes along in my case. Whatever this black magic is you used there is too high for my fried brain atm)
Credits to @mykl@lemmy.world for the approach of using reduce and also how to split the input by multiple characters.
I can happily say that I learned quite a bit today, even though the first part made me frustrated enough that I went searching for other approaches ^^
Part two just needed a simple modification. Changing how the input is parsed and passed to the adapted function took longer than changing the function itself actually.
Run with example input here
PartOne ← (
&rs ∞ &fo "input-7.txt"
⊜□≠@\n.
≡◇(⊜□≠@:.)
≡⍜⊡⋕0
≡⍜(°□⊡1)(⊜⋕≠@ .)
⟜(⊡0⍉)
# own attempt, produces a too low number
# ≡(:∩°□°⊟
# ⍣(⍤.◡⍣(1⍤.(≤/×)⍤.(≥/+),,)0
# ⊙¤⋯⇡ⁿ:2-1⊸⧻
# ⊞(⍥(⟜⍜(⊙(↙2))(⨬+×⊙°⊟⊡0)
# ↘1
# )⧻.
# ⍤.=0⧻.
# )
# ∈♭◌
# )0)
# reduce approach found on the programming.dev AoC community by mykl@lemmy.world
≡(◇(∈/(◴♭[⊃(+|×)]))⊡0:°⊂)
°□/+▽
)
PartTwo ← (
&rs ∞ &fo "input-7.txt"
⊜(□⊜⋕¬∈": ".)≠@\n.
⟜≡◇⊢
≡◇(∈/(◴♭[≡⊃⊃(+|×|⋕$"__")]):°⊂)
°□/+▽
)
&p "Day 7:"
&pf "Part 1: "
&p PartOne
&pf "Part 2: "
&p PartTwo
Welp, got frustrated again with part one because there kept being something wrong with my totally-not-ugly loop and so came here again. I did have to change
IsInt(and thus alsoCostto account for different handling) for part two though because I kept getting wrong results for my input.I'm guessing it's because uiua didn't see the difference between rounded and non-rounded number anymore.
Here's the updated, slightly messier version of the two functions that worked out for me in the end :D
~Could~ ~have~ ~been~ ~done~ ~better~ ~but~ ~I'm~ ~lacking~ ~the~ ~patience~ ~for~ ~that~ ~now~