181 lines
6.4 KiB
Org Mode
181 lines
6.4 KiB
Org Mode
#+title: Notes
|
|
* ok. only thought i had was to simulate the thing
|
|
|
|
have single executor, that takes head of the queue,
|
|
signals would be (to, from, type)
|
|
|
|
take 'to' out of the map, call it's 'process(from, type)'
|
|
|
|
and different types of executors would implement this differently.
|
|
and return a slice of new signals in order, to be appended.
|
|
|
|
if queue is empty - the single button press is propagated and all is well.
|
|
|
|
we will take snapshot of state, String() repr of all executors should be enough,
|
|
and save amount of signals sent so far
|
|
* also, i suppose i'd want to have entry points for fiddling with single executors to be test cases.
|
|
* modules to implement
|
|
** DONE Broadcast
|
|
** DONE Flip-Flop
|
|
** DONE Conjunction
|
|
** DONE Button
|
|
* i guess each module could test if string is it's a representation of this type
|
|
and would be able to parse it? into it's own struct?
|
|
well, those are just functions, since only methods are associated, so ok
|
|
* how do i run single tests?
|
|
** running tests from the module
|
|
#+begin_src bash
|
|
go test sunshine.industries/aoc2023/day20 -v
|
|
#+end_src
|
|
|
|
have file with `_test.go` and `func Test...(t *testing.T) {}` name
|
|
** running single test
|
|
#+begin_src bash
|
|
go test sunshine.industries/aoc2023/day20 -v -run TestParseFlipFlop
|
|
#+end_src
|
|
* yikes. if i don't know the 'inputs' to the conjunction, don't know how to check for 'all high'
|
|
let's add registering after the map is read.
|
|
* well. for part 2 brute force doesn't work.
|
|
how could i examine inputs to the 'rx' to see when it will receive 'low'?
|
|
|
|
i suppose inputs could be on prime cycles, which would align to all required values only on a very big step?
|
|
|
|
let's do some kind of visualiztion?
|
|
|
|
how would i do graphql or mermaidjs?
|
|
|
|
flowchard in mermaid should be it
|
|
|
|
go run . > day20/my-mermaid.mmd
|
|
* so, looking at the thingy.
|
|
rx is produced by &th
|
|
which has inputs of
|
|
11:&xn -> th
|
|
14:&qn -> th
|
|
16:&xf -> th
|
|
32:&zl -> th
|
|
|
|
|
|
for rx to receive a low pulse.
|
|
&th should receive High Pulse, while all other inputs alse remembered as high.
|
|
|
|
this is not too easy.
|
|
but first let's check if loops over
|
|
- xn
|
|
- qn
|
|
- xh
|
|
- zl
|
|
|
|
are manageable.
|
|
|
|
well.
|
|
i'll need to what?
|
|
not only track the inputs of the th.
|
|
but state of the 'subloop'
|
|
and they are separate
|
|
|
|
is there an easy way to collect the names from each subloop?
|
|
i guess i could write a collect.
|
|
|
|
from each of outputs of 'broadcast'
|
|
|
|
then have a funciton that checks loop size of each subgraphs
|
|
|
|
but i will also need to figure out on which steps output of the loop is remembered as High \ Low
|
|
|
|
let's start with loop size? and modify things if need be
|
|
** starting points of loops:
|
|
children of the broadcast:
|
|
broadcaster -> sr, ch, hd, bx
|
|
|
|
sr, ch, hd, bx
|
|
** ok. some data here
|
|
2023/12/20 12:05:06 >>> searching for loop of sr
|
|
2023/12/20 12:05:06 >>> found loop from 1 to 4028. of size 4028
|
|
2023/12/20 12:05:06 >>> searching for loop of ch
|
|
2023/12/20 12:05:06 >>> found loop from 0 to 3923. of size 3924
|
|
2023/12/20 12:05:06 >>> searching for loop of hd
|
|
2023/12/20 12:05:06 >>> found loop from 0 to 3793. of size 3794
|
|
2023/12/20 12:05:06 >>> searching for loop of bx
|
|
2023/12/20 12:05:07 >>> found loop from 0 to 3739. of size 3740
|
|
|
|
one of these guys starts from 1, not from 0.
|
|
this is unusual, but OK
|
|
|
|
now, i want to figure out what are steps where output for the each cycle is 'considered as saved as 1'
|
|
|
|
i guess i could just directly probe the
|
|
`th`
|
|
|
|
on each step up to 4028
|
|
|
|
but also, if the signallings from those are rare - would be eaiser to collect steps of each signal.
|
|
** ok. i collected 'monitored pulses' and i see lots of 'Low'
|
|
what i want is all "high" and first low after those.
|
|
** oh wow, this crap
|
|
2023/12/20 12:30:05 >>> searching for loop of ch
|
|
2023/12/20 12:30:05 >>> found loop from 1 to 3924. of size 3924
|
|
2023/12/20 12:30:05 the pulses
|
|
+map[3922:[high low]]
|
|
2023/12/20 12:30:05 >>> searching for loop of hd
|
|
2023/12/20 12:30:05 >>> found loop from 0 to 3793. of size 3794
|
|
2023/12/20 12:30:05 the pulses
|
|
+map[3661:[high low]]
|
|
2023/12/20 12:30:05 >>> searching for loop of bx
|
|
2023/12/20 12:30:05 >>> found loop from 0 to 3739. of size 3740
|
|
2023/12/20 12:30:05 the pulses
|
|
+map[3499:[high low]]
|
|
2023/12/20 12:30:05 >>> searching for loop of sr
|
|
2023/12/20 12:30:05 >>> found loop from 0 to 4027. of size 4028
|
|
2023/12/20 12:30:05 the pulses
|
|
+map[624:[high low]]
|
|
*** but at least these 'high low' are all on same step.
|
|
now with info on loop start, place of pulse in the loop and length of loops,
|
|
what is the step so that those [high low] occur on same step num?
|
|
*** math should be:
|
|
3922 + LOOP_N * (LOOP_LEN)
|
|
** wait i now get different output?
|
|
2023/12/20 12:57:50 >>> searching for loop of bx
|
|
2023/12/20 12:57:50 >>> found loop from 1 to 3739. of size 3739
|
|
2023/12/20 12:57:50 the pulses: +map[3738:[high low]]
|
|
2023/12/20 12:57:50 >>> searching for loop of sr
|
|
2023/12/20 12:57:50 >>> found loop from 0 to 4026. of size 4027
|
|
2023/12/20 12:57:50 the pulses: +map[286:[high low]]
|
|
2023/12/20 12:57:50 >>> searching for loop of ch
|
|
2023/12/20 12:57:50 >>> found loop from 0 to 3922. of size 3923
|
|
2023/12/20 12:57:50 the pulses: +map[78:[high low]]
|
|
2023/12/20 12:57:50 >>> searching for loop of hd
|
|
2023/12/20 12:57:51 >>> found loop from 0 to 3792. of size 3793
|
|
2023/12/20 12:57:51 the pulses: +map[3481:[high low]]
|
|
** why is my filtering unstable?
|
|
** let's check for single loop?
|
|
** yikes. but maybe
|
|
2023/12/20 13:08:52 >>> searching for loop of sr
|
|
2023/12/20 13:08:52 >>> found loop from 2 to 4028. of size 4027
|
|
2023/12/20 13:08:52 the pulses: +map[4027:[high low]]
|
|
|
|
2023/12/20 13:09:23 >>> searching for loop of ch
|
|
2023/12/20 13:09:23 >>> found loop from 2 to 3924. of size 3923
|
|
2023/12/20 13:09:23 the pulses: +map[3923:[high low]]
|
|
|
|
2023/12/20 13:09:37 >>> searching for loop of hd
|
|
2023/12/20 13:09:37 >>> found loop from 2 to 3794. of size 3793
|
|
2023/12/20 13:09:37 the pulses: +map[3793:[high low]]
|
|
|
|
2023/12/20 13:09:49 >>> searching for loop of bx
|
|
2023/12/20 13:09:49 >>> found loop from 2 to 3740. of size 3739
|
|
2023/12/20 13:09:49 the pulses: +map[3739:[high low]]
|
|
|
|
all loops start from same plase.
|
|
i could just do 1 press. then the loop starts. and all of them have [high low] on last place.
|
|
so it's going to be 1 + least common ...
|
|
** aaand, i just did least common multiple of the cycle lenghts.
|
|
and i didn't even added 1. which is strange. i guess i did have 'off-by-one'
|
|
crap
|
|
*** yeah. i can start from step 1. but i need to first update State then check for previous
|
|
|
|
all loops are from step 1.
|
|
|
|
it's just for some reason code was unstable when i was searching for all
|
|
*** answer is 224046542165867
|