Day 10 Part 2, bug?

[dmaahs2017]

I got stuck on part two for this problem, so I went to use your code as a reference. Updated my logic to match, which passes all the sample cases, however it does not work for my input data.

I then pulled your exact code and ran it on my input data and it does not work. I'm having trouble finding what the specific edge case is, but here is my input data https://gist.github.com/dmaahs2017/0f711278cd6a32e403c010a520f99285. The answer is not 444, answer too high.

I think this means there may be bug in your day10 part 2 solution, but you happened to get lucky with the input data not containing a particular edge case.

[attilakapostyak]

A similar algo worked for me, but looking for vec!['|', 'J', 'L']. It is dependent on how S (the start position) has its corner neighbors.
So I'm pretty sure it worked for Chris being lucky that it worked in that config for his data. The vec I have worked for my data.

So, probably this solution is far from ideal, to work on any data.

[ChristopherBiscardi]

the S position needs to be replaced by its associated pipe for the algorithm to be correct in all cases I believe. My input was definitely lucky for it to have worked this way.

[dmaahs2017]

I did some research and found a different solution which uses this concept: "if you cast a ray, that is not colinear to any of the shapes borders, from any point. That point is within the enclosed shape if the number of intersections is odd"

So I just examine all the points in the south east direction from every point, and an odd number of boundary intersections means it's contained by the loop.

And I think with this solution hitting a L or 7 is ignored because a south east ray cast hits the corner of the loop which doesn't count as an intersection. At least that's my visual rationale.. don't fully understand the reasoning. So bless TDD for sanity

https://github.com/dmaahs2017/advent-of-code/blob/master/2023%2Fsrc%2Fbin%2Fday10.rs#L139-L147

[ChristopherBiscardi]

That is the same approach I took in the solution that exists in this repo. I know it as "point in polygon" but there are absolutely other names and contexts it is used in. The big difference is I'm not doing the ray diagonally, which is the adjustment that absolves the edges issue and IMO is the better solution compared to matching any edge direction

[ChristopherBiscardi]

I intend to change the solution here to be diagonal, so I'm using this issue to track that change.

[dmaahs2017]

I intend to change the solution here to be diagonal, so I'm using this issue to track that change.

The answer for my input data is 435 if you want to use it for a test case