Got there eventually - again there was a day job to do in between parts 1 and 2. Spent a long time with a confusing off by one error caused by me forgetting that Pascal strings are 1 indexed. I have known this for over 40 years! Oh dear.
Just a heads up the part 2 solution is off by one, only for certain inputs since "The new obstruction can't be placed at the guard's starting position - the guard is there right now and would notice." And this solution does not account for this.
i don't understand one thing - why don't you need to store a direction in og_seen set? in part 2 when going through the og_seen set, you always go through directions starting from going up, even if the guard originally didn't go up, how does it work correctly? can't wrap my brain around it
bro it's like you know the question beforehand you don't even trying to read the question and graph it out just go straight to code. May I ask how did you do that?
hey, how do you get that progress bar in your terminal once you run your code? is it a vsc extenson? i also did part 2 using brute force, but with no progress bar, it was hard to know if the program was even running
your "makes_loop if right shape" logic is where I'd like to go, but the logic makes my brain hurt. (shape can be rotated, and scaled up in each dimension, and counted if missing obstacle is on current path *and* is in right orientation... yada yada)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
For bounds checking the column, we want 0
true! i've just noticed that most grids in aoc are square, so it was faster for me to think about just n and not both n and m.
Got there eventually - again there was a day job to do in between parts 1 and 2. Spent a long time with a confusing off by one error caused by me forgetting that Pascal strings are 1 indexed. I have known this for over 40 years! Oh dear.
woah! using pascal sounds super cool. glad you got it!
I did exactly the same approach execpt the checking only the guard paths
this is good enhancement for performance thank you William
Imagine waiting all that time for the bruteforce to finish and then finding out the answer is wrong lol
that would be horrible 😓 but getting the right answer on part 1 gave me confidence!
Just a heads up the part 2 solution is off by one, only for certain inputs since "The new obstruction can't be placed at the guard's starting position - the guard is there right now and would notice." And this solution does not account for this.
true! let me fix this.
i don't understand one thing - why don't you need to store a direction in og_seen set?
in part 2 when going through the og_seen set, you always go through directions starting from going up, even if the guard originally didn't go up, how does it work correctly? can't wrap my brain around it
i believe the problem statement says that the guard always originally faces up.
bro it's like you know the question beforehand you don't even trying to read the question and graph it out just go straight to code. May I ask how did you do that?
i look at the example inputs to try and understand how the problem works. usually reading all the flavortext is not requred.
hey, how do you get that progress bar in your terminal once you run your code? is it a vsc extenson? i also did part 2 using brute force, but with no progress bar, it was hard to know if the program was even running
There are some python libraries that can do the progress bar . Here he uses tqdm.
yep, i use tqdm (github.com/tqdm/tqdm). very convenient, pretty much a drop-in for automatic progress bars.
Cool!
your "makes_loop if right shape" logic is where I'd like to go, but the logic makes my brain hurt.
(shape can be rotated, and scaled up in each dimension, and counted if missing obstacle is on current path *and* is in right orientation... yada yada)