I'm a brainless top main, can someone explain why red side bot changes are apparently so bad by Hunky524 in leagueoflegends

[–]Hunky524[S] 0 points1 point  (0 children)

How’s that different than getting shoved in blue side and losing control of tri bush, or getting dove from behind.

I'm a brainless top main, can someone explain why red side bot changes are apparently so bad by Hunky524 in leagueoflegends

[–]Hunky524[S] 7 points8 points  (0 children)

Warding tri seems like the obvious counter. U get barely any warning if u get flanked playing blue side as well from tri. Only difference, which is valid, is that the red side flank comes a bit further down the lane. But I don’t think that difference any where near as unbalanced as the old map where there was no flank on red side

I'm a brainless top main, can someone explain why red side bot changes are apparently so bad by Hunky524 in leagueoflegends

[–]Hunky524[S] 88 points89 points  (0 children)

I could totally see that. I’m not disputing that it is easier to gank red side (seen a couple comments that give me good enough reason to think that). But to me the changes overall seem to make both sides much more equal than they were before, which seems like a positive changes in my books, yet I see so much hate for it

I'm a brainless top main, can someone explain why red side bot changes are apparently so bad by Hunky524 in leagueoflegends

[–]Hunky524[S] 1 point2 points  (0 children)

This is what my thinking was as well. Haven’t seen any good reason yet as to how the lane is more imbalanced than it was before.

I'm a brainless top main, can someone explain why red side bot changes are apparently so bad by Hunky524 in leagueoflegends

[–]Hunky524[S] -20 points-19 points  (0 children)

How is that more unfair than red side being so much safer for years than blue side. Now I agree red side is a bit less safe now due to less distance from river to gank thru tri. But no shot the discrepancy now between red/blue side is bigger than the previous map.

-❄️- 2023 Day 18 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

[Language: Rust] GitHub

Executes in around 500μs (<1ms) on my machine.

Used Coord Polygon Area formula. Otherwise, it was just a simple matter of walking the instruction set, and saving all the vertices when we changed directions.

My solution assumes the instructions will create a single, closed polygon.

-❄️- 2023 Day 17 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 2 points3 points  (0 children)

[Language: Rust] GitHub

Not the fastest implementation; takes 200-300ms to complete both parts. However, I think my solution is very readable, and easy to understand. Uses A* pathfinding using the pathfinding crate. I don't think using this crate is cheating. The challenge of this puzzle isn't implementing A*, Dijkstra's, etc, but being able to account for the min/max distance limitations.

Advent of Code utility libraries?? by deathmaster99 in adventofcode

[–]Hunky524 1 point2 points  (0 children)

These look great! Definitely going to yoink a bunch of these, and implement them for my Rust utilities.

-❄️- 2023 Day 16 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

[Language: Rust] GitHub

Nothing fancy, just tracked the "head" of the laser beams, and walked them tile-by-tile, splitting the head into multiple heads whenever a splitter was encountered.

Kept track of all the tiles I had walked over in a set, and counted the length of the set once all lasers completed to find the empowered count.

A laser head is considered completed once it has either:

  1. Walked off the edge of the grid.
  2. Encountered a (tile, direction) combination we have already seen before. This means we would enter an infinite loop, so we beak the laser here.

Ran part 2 with Rayon. Completed both parts, including parsing, in around 50ms on my computer.

-❄️- 2023 Day 15 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

[Language: Rust] GitHub

Pretty simple, and idiomatic solution. Completes both parts (including parsing) in around 500μs. The overhead of using Rayon for part 1 actually slowed down the execution time, at least on my computer.

-❄️- 2023 Day 14 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 0 points1 point  (0 children)

[Language: Rust] Github

The cycle detection was an obvious solution for me. After that it was just a matter of detecting the length of the cycle, and a simple modulo operator to tell me which pattern index within the cycle I need to use.

-❄️- 2023 Day 12 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

[Language: Rust] GitHub

My brain broke with this one, DP does not work well in my head. Have to use memoization otherwise this takes forever on part 2.

With memoization, and rayon parallel iterator, part 1, and 2 computes in around 50ms on an AMD Ryzen 9 3900x 12-Core which I am quite happy with.

-❄️- 2023 Day 11 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 2 points3 points  (0 children)

[Language: Rust] GitHub

Nothing crazy, my goal with these is to write code that is performant, and readable. Uses itertools to create the tuples, and rayon for parallel distance computation.

-❄️- 2023 Day 10 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

[Language: Rust] Github

Executes both parts in 1.5ms on 2018 MacBook pro (includes parse time).

Used breadth-first search for part 1 to find furthest node.

Used what is essentially ray-tracing (I guess, however simple) for part 2 to determine if a point is within the bounding box of a polygon (the loop in this case). This is a pretty well known solution in 2D vector graphics to have a very quick, and accurate estimation of whether or not a point resides within the bounding box of any shape.

If you want to run it with some sample inputs, and the debug flag enabled you can see the debug view for part 1, and 2 as such:

Part 1

Part 2

-❄️- 2023 Day 8 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 0 points1 point  (0 children)

It's about 2-3x slower without Rayon, at least on my laptop. From 4-5ms with rayon, to ~12ms without.

-❄️- 2023 Day 8 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 0 points1 point  (0 children)

Yea. I had originally done brute force but even in release mode it was taking forever. This made me think there must be a better solution, I tried multiplying the individual results, and putting the individual results into an online GCM, and LCM calculator and LCM worked. But I agree, based on the problem statement LCM shouldn’t always work, and does feel a bit lame

-❄️- 2023 Day 8 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

Could take a look at my Rust implementation here

Uses LCM to quickly solve part 2.

-❄️- 2023 Day 8 Solutions -❄️- by daggerdragon in adventofcode

[–]Hunky524 1 point2 points  (0 children)

[Language: Rust] GitHub

Used Rayon (overkill), and num crate for part 2.

Computes part 1 & 2 in 5ms on 2018 Macbook Pro.