[SPOILER ALERT] Advent of Code: Day 14 solutions

It's possible to brute force part 2 by simulating every unit of sand dropped. I will draw a complete picture in my next (minimized) post.

The brute force solution takes about 12 seconds on my machine, but the image it produces clearly hints at a much faster solution that determines the size of the "shade" that each platform casts below it.

How do you minimize a post, anyway?

I posted my own part 2 image in the main AoC 2022 thread, before seeing this thread.  If someone wants to minimize it there for me, or delete it, feel free, and I will put it in this thread instead.

I didn't really think of this as "brute force", and I can run parts 1 and 2 combined in 0.3-0.4 sec.  Is it possible you're printing too many intermediate results?  Output along the way can slow things down - especially giant ASCII images.  

Having said that, yes it's true that it seems like an even faster algorithm is possible, for part 2.  I may have to work that out too, for fun.  Good catch.

This was the most fun puzzle so far, for me.  

OK, this new method speed up part 2 from about 0.4 sec to just under 0.1 sec:
private val flowDirections = listOf(Vector(0, 1), Vector(-1, 1), Vector(1, 1)) private fun alternateFillForPart2(grid: Grid): Int {    val queue = ArrayDeque<Vector>()    queue.addFirst(SOURCE_POINT)    var count = 0    while (queue.isNotEmpty()) {        val p = queue.removeFirst()        if (grid[p] == EMPTY || p == SOURCE_POINT) {            grid[p] = SAND            count++            flowDirections.forEach { queue += p + it }        }    }    return count }
This uses my previous code to populate the grid based on the input file (including the infinite floor for part 2) - the fill method just fills in the sand and returns the amount sand used. This was actually simpler than the original fill method, as well as faster.  Though the original had the advantage of being usable for part 1 and part 2.  This one only works for part 2.

[Edited to add:] Note that Vector here is not a java.util.Vector (ugh!), but a typealias for a custom class of mine, IntVector2D, that represents an actual vector in the traditional match/science sense, a quantity with two or more dimensions, e.g. x and y.   With some overloaded methods that allow me to add vectors easily with a + operator, things like that.  So "queue += p + it " actually means "queue.addLast(p.plus(it))".  I was previously calling this class Point (or IntPoint2D), but decided Vector is better since that's a more generalized term.  Sometimes it represents a delta between two points  rather than a point, for example.  I feel it's time to reclaim the term vector for its proper math/science usage.

I believe my performance issues stem from the fact that i made my Cave class immutable, and each time a new unit of sand is added, the entire Cave is copied.