#+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