22a input parsed

21b done

21b that does something useful

It constructs a function to evaluate the result, so then we can make
it depend on the human's number.

21a: pull out opcode decoding

21a simplified

Less cleverness, more flexibility for 21b

21a done

20b done

The problem was that my input included repeated numbers, so I needed to
keep track of which instance of a repeated number I was moving.  I
achieved this by applying the mixing operation to a list of indices into
the original array, looking up shift amounts in the original array and
translating back to the original values at the end.

20: trivial simplification

20b: working on the example

But not the real input

20a done

Thanks to cardboard Verity for providing the answer, which is that it
doesn't matter where the start of the list is: everything treats it as
circular.

20a: slight simplification

20a example OK

Fails on the real input though.

20a closer

Now the only problem is when a number lands precisely on the boundary.

20a doesn't work

It's a pretty solution, but the problem statement has different ideas
about what moving an element past the end of the list means.

19a even faster

Merging the two "is it worth it?" checks.

19a: much faster

We now don't build a robot if our production rate of it resource is
enough to build a new robot of the most expensive kind every minute.

19a: correct maximum-cost calculation

19a done

19a gets the example blueprint 1 right

Takes 17.8 seconds to do so.

19a: this approach almost works

But not close enough to continue with it.

19b done

16a: use fact that ⍟ can take an array of repetition counts

18a: comment correction

18a done

17b finally done

I got confused and forgot that jets didn't reset for each rock.  Once
that was fixed it was only a bit slow.

17b works on example

17a done

17a starting to work

need to not restart jet sequence for each rock, though

16b done

A little light memoization did the trick (but 27s CPU time!)

16a done

16a: example completes in reasonable time

16a: faster search, now 19 levels in a minute

16a: correct but slow exhaustive search

15b done

Utter mess with lots of debugging, which I've left in for posterity.

15b: found constraining beacons

15a done

15a: input parsing

14b done

I dodged the bug by sticking the floor on by simpler means.

14b kind of works but gives weird internal CBQN errors

14a done

14a: map constructed

14a: short-circuit boolean ops because I think I'll need them

13b done

13a working on the example but probably subtly wrong

13a: most of the list parser done

12: factorise contruction of can_go_x arrays somewhat

12: Use the primitive •_while_: it's actually easier to understand

12b done

12a done

11a: faster Inspect copied back from 11b

11a and 11b done

10b done

10a done

09: prep cleanup

09b done

09a: restructure to calculate head and tail paths separately

09a: split head and tail steps

09a done

09a working on example

09a: successfully tracing path using fold

08: explicitly construct rotations as powers of ⌽∘⍉

08: rotate maps rather than mirroring

This is now consistent across 08a and 08b.

08b done

08a done

07: slight cleanups though I'm still not happy

07b done (also slight readability improvement in 07a

07a done

07a: store paths in the normal order (root to leaf)

07a: extract only regular files

07a: got a list of files with full paths

07a trivial CLI that can cd

06: simplify code to use monadic / (Indexes)

06b done

06a: parameterise main block by length of marker

06a gratuitously more tacit version

06a done

05: simpler Prep

05b: remove a comment that only applied to 05a

05a: another place where a scalar can be automatically promoted

05a: slightly simpler Prep1Proc

05b done

05a: slightly prettier ExecuteMove

05a done

Tidy up and comment map prep in 05a

Prep for 05a

A bit more Split fettling in 04

It was silly to have an operator that immediately called its operand on
its argument and did nothing else with the operand.  Better to have a
function that takes the output of the operand as its left argument.
That avoids the confusion I had over whether the operator should take a
function that acts on a single element or on the whole list: it now
takes neither.

This doesn't even make calling the function any harder. It just changes
F _split x into F⊸Split x.

git ignore *.eg and *.in

Those are the names I use for my input files

Genericise Split to modifier _split in 04

04b done

04a done

Slight simplification of 03b

I think I've understood ˘ now.  It's like ¨ but for rows rather than
elements.

03b done

Still don't really understand the interaction of ˝ and ˘ though.

03a done

03a just needs priority

02a and 02b done

01b done

01a done