126 lines
4.1 KiB
Org Mode
126 lines
4.1 KiB
Org Mode
#+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.
|
|
** 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
|
|
* maybe new approach?
|
|
make a graph. with vertices of Start, End and Crossroads.
|
|
yes.
|
|
let's create a graph representation.
|
|
** so, from A to AG
|
|
i think i can do this manually now
|
|
** distances are
|
|
39
|
|
244
|
|
184
|
|
154
|
|
214
|
|
378
|
|
144
|
|
190
|
|
40
|
|
184
|
|
152
|
|
172
|
|
166
|
|
102
|
|
158
|
|
166
|
|
140
|
|
118
|
|
108
|
|
268
|
|
110
|
|
72
|
|
56
|
|
142
|
|
146
|
|
110
|
|
128
|
|
190
|
|
108
|
|
174
|
|
77
|
|
1
|
|
** again?
|
|
no, let's write code.
|
|
** didn't count all the way
|
|
2023/12/23 15:55:55 at {index:30 c:{Row:125 Col:137} name:f} to {index:31 c:{Row:140 Col:139} name:g} cur dist is 3997. |max so far 6406|
|
|
signal: interrupt
|
|
FAIL sunshine.industries/aoc2023/day23 380.499s
|
|
|
|
tried more or less stable value, and interrupted
|