Day 6: Guard Gallivant

Megathread guidelines

  • Keep top level comments as only solutions, if you want to say something other than a solution put it in a new post. (replies to comments can be whatever)
  • You can send code in code blocks by using three backticks, the code, and then three backticks or use something such as https://topaz.github.io/paste/ if you prefer sending it through a URL

FAQ

  • @Leavingoldhabits
    link
    3
    edit-2
    5 days ago

    Rust

    This one was the first real think for this year, but I ended up brute forcing it, placing a ‘#’ in every position and checking. part 2 runs in about 380ms 78ms (after reducing the amount ‘#’-placements to only where the guard walks) on my 2011 core i-7, so I’m happy, even though it feels like I could have been smarter.

    Part 1 Part 2

    • @[email protected]
      link
      fedilink
      2
      edit-2
      5 days ago

      I am doing the same principle brute force but it takes ~7 seconds oO

      Is using a HashSet<(Pos, Dir)> for the loop detection so expensive? My CPU shouldn’t be THAT bad…

      Part one around 7ms.

      Also curious that i have not seen someone mention a more efficient approach, there gotta be one?

      • @aoidenpa
        link
        2
        edit-2
        4 days ago

        I created rows and cols vecs that keep places of blocks. When moving, I binary search the row or col, find the block that stops me. So moving whole sections at once. Otherwise used HashSet of pos and dir like you. Also in part 2, place the new block only on the path I take in part1. Part 2 is 26ms.

        code

        • @[email protected]
          link
          fedilink
          24 days ago

          The binary search sounds smart, would reduce the pathing quite a bit i guess :)

          Part 2 i approached quite the same i think, was only a couple lines of code additionally. But running 5ms 5000 times is also gonna take a while…

      • @[email protected]
        link
        fedilink
        3
        edit-2
        5 days ago

        I draw ^>v< characters on the grid while walking, so then it’s a direct array lookup (instead of a hashtable). The representation could be better though, some kind of bitmask would beat checking against a bunch of characters.

        • @[email protected]
          link
          fedilink
          14 days ago

          I dont change the map, i just record the steps in the hashtable. But maybe drawing on the map is indeed shaving some time off, thanks for the input :)

          • @[email protected]
            link
            fedilink
            14 days ago

            It probably won’t matter a whole deal but array indexing involves no comparisons or searches. And I found it convenient too!

      • @Leavingoldhabits
        link
        2
        edit-2
        5 days ago

        I’d like to see your solution in total. I’m not too familiar with the nuts and bolts, but hash set is quite a bit more expensive than a simple vector, there’s a bunch of overhead incurred when executing the hashing and placing of the data, and when repeating a few thousand times it sure adds up. My part one hovers around 600 microseconds.

        • @[email protected]
          link
          fedilink
          24 days ago

          I’d like to see your solution in total.

          I set it up a bit like a game, https://pastebin.com/FGA6E7fA

          My part one hovers around 600 microseconds.

          Ohhh, that says my part 1 is slow already, i was sure my approach for 2 was the problem. Good to know!

      • @[email protected]
        link
        fedilink
        14 days ago

        Alright, I completely forgot about --release because i normally use just to run my stuff. That brings part 2 down to around 400ms, i am okay with that for now :D