efim/Advent-of-Code-2023
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

day23: started hardcode of part2, way too slow

Browse Source
This commit is contained in:
efim
2023-12-23 10:19:25 +00:00
parent 44de1377ca
commit 7ebb6dee2c
4 changed files with 101 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
day23/notes.org Normal file
View File

@@ -0,0 +1,67 @@
#+title: Notes
* ok, second part is long.
and here optimization of storing direction of enter into path, and it's length,
would that be helpful?
it might not, because based on visited some future longer path might not be available.
i don't know how to optimize.
i could maybe do same calculation in parallel, somehow
put not into queue, but into channel
* wait a second. previous answer was 2018
and now long checks result in me waiting for intermediate 1882.
let's add early cutoffs, if not end by 2018, then abandon
doubt that's implementable
* well. do i want to try parallel?
seems like false path, really
like there should be a better optimizaiton first
* maybe we could join detours into 'potential longest paths'
like if we traverse, and get to a point which was previously visited,
for evey path that went through that split path,
i could check whether i can take paths that went through this point, and switch their part with the detoured part.
* and maybe we could continue longest paths first?
like making pathsToFurther a heap by visited.Cordinality ?
oh, and then we'll find 'some path to end'
and additional paths will try to add their detour.
so, i guess when finding a path to end, i could save path to end for each point.
then if i reach the point, i could check if i can use some of the
and i guess if i do depth first then i'll always have all paths to end from a point if i return to it?
* this sounds like an idea.
with heap do depth first.
if it's first visit to a point, just go further
if i find the end, i'd want to mark all points on the path with path info
hm. recursive calls might make this easier.
because i'd want both 'prefixVisited' set and totalPathSet
due to depth first, we'll discover shortest path first.
and points will get mapped with this first (of potential multiple) path info to end.
now if on followup steps i get into the point with info on paths to end,
that should mean that i've already found all paths to end from that point, right?
now i need to check for the 'detour' which 'paths to end' are still possible with that detour added
by taking set of elements from this point, to end. and checking that intersection with detour elements is 0.
if there are like this - report finding a new path, and save to all elements of that path somehow.
and now on finding detours i wouldn't need to re-check path to end, that should save a lot of time
** so how to go about in coding this?
have shared map[Coord][]EndPathInfo
the DFS means i'm recursing into each child.
and taking the result of the call.
it should be info on path to end? or multiple paths to end.
which should be added to current node.
and then calling with start point will return paths to end from start, and i'll be able to take the by length
ok. but. if i'm entering the coord, and there are already paths to end.
then i need to presume that those are only possible paths to end from this point,
because all other paths should have been explored by now,
i for my 'detour' determine whether it is consistent with any of already found paths to end.