3.5 KiB
Notes
- ok, second part is long.
- wait a second. previous answer was 2018
- well. do i want to try parallel?
- maybe we could join detours into 'potential longest paths'
- and maybe we could continue longest paths first?
- this sounds like an idea.
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.
NO. dfs doesn't mean i'll find shortest path first.
so if i'm in visited, it doesn't mean that stored is shorter and current is a detour.
but dfs should mean that all paths from this prefix have finished. so, sure. there have to be all done?
my example2 has fork on row 3 col 10
so 4,10 and 3,11 should be visited separately.
6,17 is where they join and the point which should have second entry
allright, ugh. my new solution is memory hogging.
maybe i can draw the stuff and it will be several neat thingies