I wanted to get an idea of how the blocks were landing and here's some thoughts on what I came up with:

• they were building a simple maze (duh I guess).
• the final (blocking) block is highlighted as a tiny red dot for half a second or so (edit: now flashing!).
• my generated path jumped about seemingly at random even when blocks landed elsewhere so I don't animate the dropping of the first 1000 blocks as it's more noise than data.
• the ~500 blocks before the final one don't affect my path at all, so it's quite a boring end.
• Lemmy doesn't like long animations, so I skip 10 blocks at a time.

If you want to toast your CPU for a few seconds, here's some terrible Uiua code.

Data  ← ≡◇(⊜⋕⊸≠@,)°/$"_\n_" &fras "AOC2024day18.txt"
End   ← 70_70
Count ← 1024

D₄      ← [1_0 ¯1_0 0_1 0_¯1]
Valid   ← ▽¬⊸∊:▽⊸(≡/××⊃(≤⊢End|≥0))+D₄¤
BestLen ← ⍣(-1⧻⊢path(Valid|≍End)0_0↙:Data|∞)
Chop!   ← ◌⍢(⨬(⊙◌+1|⊙⊙◌:):⟜^0⌊÷2+,,|>)

BadBlock ← -1Chop!(=∞BestLen)Count ⧻Data
Skip     ← 1000
Step     ← 10
Times    ← ⍜(-Skip|⁅⍜(÷Step|⇡⌊))+1BadBlock

# paths - will ruthlessly spawn new threads until your CPU burns.
∵(×1_1_0)wait≡spawn(°⊚°□⊢path(Valid|≍End)0_0↙:Data)Times

¤∵(×0_0_1)⬚0+↯+1End0°⊚↙Skip Data           # old blocks
+:∵(×0_1_1)≡(⬚0+↯+1End0°⊚↘Skip↙)Times¤Data # add new blocks
≡+                                         # superimpose
⊂:⍜(⊡|⋅1_0_0) ⊡BadBlock Data⊣.             # Add frame for final block.
⍥(⊂:↙¯2.)10                                # Freeze frame.
≡(▽⟜≡▽4)                                   # Scale up.
&fwa "AOC2024day18.gif"gif 60

I've had a few comments on my Uiua solutions asking how you're even supposed to understand them, so I thought I'd write a little explainer.

Uiua is a new language that uses the array programming paradigm (other languages in this family are APL, J, K, R and BQN). This approach recognises that a great deal of programming is about the manipulation and interrogation of arrays of data and so provides tools to handle arrays of data as fundamental units. So rather than building nested for-loops to access data items, you manipulate the array as a whole, e.g. to add 1 to every element of a multi-dimensional array A, you would simply write +1A. This approach not only makes some aspects of programming easier, it also means that the compiler can generate extremely efficient code, and in principle make use of massively parallel processes for further speedups (I don't know to what extent Uiua supports this). Array programming languages are very useful for people who want fast processing of large amounts of multidimensional data, e.g. audio, video, scientific data, or financial data.

There are three factors that can make Uiua code hard to understand.

First, as we have already seen, Uiua is an array programming language, which not only mean that it uses a very different approach to problem solving, but that it also inherits that family of language's love of using glyphs for operator names rather than ascii names. Using the Uiua online editor and learning the documentation are the only ways to deal with this massive barrier :-(

Second, Uiua is stack based, so values are normally held on the stack rather than in named variables. This introduces some of the same challenges as writing in Factor, Forth etc, where you have to build up a mental model of what's on the stack at any time. There are variables available, but idiomatic code tends to avoid them as far as possible.

Third, function application is generally in mathematic order i.e. right-to-left. This can be complicated by some operators having different numbers of arguments which affect the binding order, but you learn to see through that…

Okay, so given all of that, how does one interpret some Uiua code? Let's work though my solution to day seven.

Data   ← ⊜(□⊜⋕⊸(¬∈": "))⊸≠@\n "190: 10 19\n3267: 81 40 27\n83: 17 5\n156: 15 6\n7290: 6 8 6 15\n161011: 16 10 13\n192: 17 8 14\n21037: 9 7 18 13\n292: 11 6 16 20"
Calib! ← ≡◇⊢▽⊸≡◇(∈♭/[^0]:°⊂) # Calibration targets which can be constructed from their values.
&p/+Calib!⊃(+|×)Data
&p/+Calib!⊃(+|×|+×ⁿ:10+1⌊ₙ₁₀,)Data

What the heck does it all mean?

Let’s find out! We'll go through it step by step.

Line 1

Data ← ⊜(□⊜⋕⊸(¬∈": "))⊸≠@\n "190: 10 19\n3267: 81 …. a string ….”

⊜(…)⊸≠@\n Can be read as partition (⊜) the string by building an array of sub-strings where each char is not \n (≠@\n) then perform the first function (i.e. the code in parentheses) on each sub-string in turn, concatenating each of the results into an array.

□⊜⋕⊸(¬∈": ") For each of these sub-strings, we immediately re-partition it by only keeping those characters that are not in string “: “, and then for each of these resulting (sub-sub-)strings, parse it as a number (⋕). As each of the lines has a different number of entries, the outer partition would not be able to build a regular array, so we box (□) each line before passing it out to hide the contents away, allowing the outer array to be built successfully.

So at this point, Data has been defined as a constant looking something like [[190 10 19] [3267 81 40 27] …etc… ]

Line 2

Calib! ← ≡◇⊢▽⊸≡◇(∈♭/[^0]:°⊂)

Calib! is a ‘macro’, that is a function that takes a function as its first argument and then inserts it into its own body whenever it sees a ^0

▽⊸≡◇(…) Means only keep those lines of the array that meet a certain condition (▽⊸≡◇ reads as “keep by rows content” where 'content" means 'look inside the box').

∈♭/[^0]:°⊂ This is where the power of an array programming language really starts to show.

For each row of the input this is passed the numbers in that row as an array. First we remove the first entry (our target) and push it down the stack for later :°⊂.

Then we reduce (/) the rest of the array by repeatedly applying a function on the result so far and the next element. The function here is partially suppled by the macro substitution, so for part 1 this would be in full [⊃(+|×)] This means ’take the two arguments and fork (⊃), or perform two functions on them, wrapping the results in an array [...].

Some magic happens here: Uiua supports ‘pervasive’ application of functions, so executing + 5 [[1 2] [3 4]] gives [[6 7] [8 9]]. For each succeeding entry in the list of numbers, we’re adding, and multiplying (and concatenating for part 2) it to every existing result, and storing these new results in a new dimension of the accumulated array.

Finally, we flatten (♭) this monstrous array into a single list of numbers and check whether that target value is in this list (member ∈) . That true/false is passed out to the surrounding ‘keep’ functionality.

≡◇⊢ Now we have kept only the lines where the target can be calculated from the numbers. So all we have to do is pass back the ≡◇⊢ “rows contents first” i.e. the first number in each line.

Lines 3 and 4

&p/+Calib!⊃(+|×)Data
&p/+Calib!⊃(+|×|+×ⁿ:10+1⌊ₙ₁₀,)Data

Call the macro on the data array, with the two different sets of operators. /+ is reduce (/) by addition (i.e. sum the results).

+×ⁿ:10+1⌊ₙ₁₀, Takes a copy of the second number, get the floor of the base-10 log, adds 1, raises 10 to that power and multiplies the first number by that before adding the second number. This is an arithmetic concatenation, which works as a pervasive operator as discussed above. [N.B. I just couldn't get ⋕$"__" or similar string approaches to work in this context. If you know how to, please let me know!]

That's it. Problem seven dealt with in 72 tokens :-)

Next steps

If you want to learn more run the code, read the Uiua language tour, explore that website and documentation, or ask away here. I'm by no mean an expert, but I'm happy to help with the basics.

I created this group last year but soon found that there was a lot more active group on programming.dev with many more participants and even a private leaderboard, so you should probably head on over there!

Happy coding everyone!

Am I in danger?

Thanks Homer.

How was day one for everyone? I was surprised at how tricky it was to get the right answer for part two. Not the usual easy start I've seen in the past. I'd be interested to see any solutions here.

Hi All, I posted here recently that I was spending November revisiting my AOC 2022 solutions (written in Dart) and posting them for reading, running and editing online.

With my last solution being posted yesterday, the series is now complete, and might be interesting if anyone's looking for an idea of the level of difficulty involved in a typical year.

To ensure that this post isn't just about posts on other communities, I've added a little bonus content - a simple visualisation I created for my solution for day 14 (flowing sand).

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today was the final challenge for the year, and as usual was quite simple and had only one part. This involved parsing and process numbers written in what I learned was called "balanced base five" notation.

Thanks for following along, now we just need to wait a few days to see what this year holds!

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today had us running round a maze with moving obstacles. Treating time as a dimension allowed me to build a graph and find the shortest path. Part 2 just required doing this three times. This took me closer than I like to a full second runtime, but not close enough to make me re-think my solution.

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today was a kinda variant of Conway's Game of Life: we had to move elves around according to a set of rules while avoiding collisions and observe the size of the bounding box after 10 rounds. Part 2 asked us to run until the pattern stagnated. Nothing clever in my solution as most of the challenge seemed to be in understanding the rules correctly :-)

The ![email protected] community is currently without an active mod: the original creator does not seem to have been active on Lemmy in months. I PM’d them to check whether they were still interested in the community and have received no reply.

I'm presently more or less the only active poster there, though that may change next month when this year's Advent of Code kicks off.

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today started quite easily: build a map and then follow some directions to navigate around it. Part 2? The map is now wrapped around a cube. Oof. I dealt with it by setting up logic for an "ideal" cube layout, and then mapping the provided definition onto that. Oddly, my solution for part2 seems to run faster than part1 despite all the added complexity...

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today was again quite an easy one, requiring us to build up a tree of values and operations on those values. Part 1 had us evaluate the root value, and part 2 required us to change the value of a specific node to ensure that both branches below the root node evaluated to the same value. The linear nature of the operations allowed me to just try two different values and then interpolate the correct answer.

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today came as a welcome relief after two tricky days! We had to jumble a file according to some simple rules. The biggest challenge was interpreting the instructions correctly; the solution itself took only a few lines. Part two just added a key and increased the number of iterations. My original approach still ran in under a second (0.7s) so I didn't bother looking into it any further, and just enjoyed the free time :-)

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today was a sudden increase in difficulty (for me anyway). We had to find the best route for opening a system of valves to maximise the total flow through the network. Part two repeated the exercise, but with the addition of a friendly elephant to help with the work.

I was able to simplify the network enough to solve part 1 in a reasonable time, but had to hack my solution for part 2 terribly to get it under a second. Reading some other solutions, I missed out on some key approaches including pre-calculating minimum paths between all pairs of valves (e.g. using the Floyd–Warshall algorithm), aggressive caching of intermediate states, and separating out my movements from the elephant's movements.

Go and read @[email protected]'s Clojure solution for a much more thoughtful approach :smile:

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today had us finding the surface area of a cluster of cubes, first in total, then excluding any internal voids. Nice and easy compared to the last couple of days!

As a warmup for this year's Advent of Code, I'm re-reading and posting my solutions to last year's challenges. You can read, run and edit today's solution by following the post link.

Today's challenge had us building a simple Tetris clone with the additional twist that a regular sequence of jets of air blow the falling pieces sideways. Part two asked us to model this for a bazillion cycles, so we needed to keep an eye on the pattern of landed blocks and look for the same pattern to repeat.