It sounds like interesting things to read, especially unusual fixes on older hardware in adverse conditions.
As mentioned you can start off here on Lemmy to see if it gets traction, and then move to a dedicated place. Or just keep posting here on Lemmy :)
No macro keys on the left, but the whole keyboard can be macro-ed. Also the hall effect switches are just about indestructible.
But… Yaml ain’t markup language…
Maybe mermaid fits your use case?
Had that issue too, search in Start for “Default Apps”, then scroll to the bottom and click “Choose default application by file type”. Then scroll to .pdf and choose Sumatra. The settings window may crash for some reason, but for me the file association did seem to stick after that.
Heavy stuff first, cold things together, fragile stuff last.
Try Bricklink, I’ve purchased “old” sets there for a decent price. Be sure to check the seller’s rating/reviews
I optimized Part1 by directly referencing workflows between each rule (instead of doing a table lookup between them), in expectation of part 2 needing increased performance. But that turned out to not be needed 😋
I had to dig through my dusty statistics knowledge for part 2, and decided to try out Mermaid.js to create a little graph of the sample input to help visualize the solution.
After that it was pretty straightforward.
This was actually something I learned for my job, it was nice to be able to apply it here.
I like your commitment to wheel-reinvention, it can be a lot more fun than going for an existing or ‘intended’ approach.
Good job on persevering with this one. Your approach for part 2 sounds quite viable, it is very similar to the Ear clipping method for triangulating a polygon.
Decided to go for a polygon approach for part 1 using the Shoelace formula to calculate the area. This meant part 2 only resulted in larger values, no additional computation.
Code runs in <1ms for part 1 and 2 combined
python-level intuitive-to-read language with static typing
Agreed, this is exactly Nim
Fork is great!
Yeah the descriptions contain a lot of story fluff, but also critical bits of information.
Happy I decided to not actually expand anything. Manhattan distance and counting the number of empty rows and columns was plenty. Also made part 2 an added oneliner :) It’s still pretty inefficient iterating over the grid multiple times to gather the galaxies and empty rows, runtime is about 17ms
I could also extract and re-use my 2D Coord and Grid classes from day 10, and learned more about Nim in the process ^^
Yepp, this one got me as well! I found the discrepancy when testing against the sample through, which showed the result for a factor 100 (which needed to be 99). Knowing the correct outcome made debugging a lot easier.
I always make sure my solution passes all the samples before trying the full input.
This was a great challenge, it was complex enough to get me to explore more of the Nim language, mainly (ref) types, iterators, operators, inlining.
I first parse the input to Tiles stored in a grid. I use a 1D seq for fast tile access, in combination with a 2D Coord type. From the tile “shapes” I get the connection directions to other tiles based on the lookup table shapeConnections. The start tile’s connections are resolved based on how the neighbouring tiles connect.
Part 1 is solved by traversing the tiles branching out from the start tile in a sort of pathfinding-inspired way. Along the way I count the distance from start, a non-negative distance means the tile has already been traversed. The highest distance is tracked, once the open tiles run our this is the solution to part 1.
Part 2 directly builds on the path found in Part 1. Since the path is a closed loop that doesn’t self-intersect, I decided to use the raycast algorithm for finding if a point lies inside a polygon. For each tile in the grid that is not a path tile, I iterate towards the right side of the grid. If the number of times the “ray” crosses the path is odd, the point lies inside the path. Adding all these points up give the solution for Part 2.
Initially it ran quite slow (~8s), but I improved it by caching the tile connections (instead of looking them up based on the symbol), and by ditching the “closed” tiles list I had before which kept track of all the path tiles, and switched to checking the tile distance instead. This and some other tweaks brought the execution speed down to ~7ms, which seems like a nice result :)
proc solve*(input:string):array[2, int]=
let lines = input.readFile.strip.splitLines.filterIt(it.len != 0)
# build grid
var grid = Grid(width:lines[0].len, height:lines.len)
for line in lines:
grid.tiles.add(line.mapIt(Tile(shape:it)))
# resolve tile connections
for t in grid.tiles:
t.connections = shapeConnections[t.shape]
# find start coordinates and resolve connections for it
let startCoords = grid.find('S')
let startTile = grid[startCoords]
startTile.connections = startCoords.findConnections(grid)
startTile.distance = 0
# Traverse both ends of path from start
var open: Deque[Coord]
open.addLast(startCoords)
while open.len != 0:
let c = open.popFirst # current coordinate
let ct = grid[c] # tile at c
#find and add connected neighbour nodes
for d in ct.connections:
let n = c+d
let nt = grid[n]
# if not already on found path and not in open tiles
if nt.distance == -1 and not (n in open):
nt.distance = ct.distance + 1
result[0] = max(result[0], nt.distance)
open.addLast(n)
# Part 2
for c in grid:
let ct = grid[c]
#path tiles are never counted
if ct.distance >= 0:
continue
# search from tile to end of row
var enclosed = false
for sx in c.x.. 0):
enclosed = not enclosed
result[1] += ord(enclosed)
I looked into the iterators and they are really handy, they remind me of C#'s Linq syntax.
Hey, I’d like to check your blog, but I get a 504 Gateway Timeout :S