Hmm... that's really neat.
Personally, I would use J's cut rather than <;._1 ' '&, but that's
pretty minor. (Also, I got rid of the fwrite -- to inspect i, I
instead used 9!:37]4$0 512).
(Also, for my own sanity, I removed the "0 from the trailing edge of
the i0..i13 verbs and instead put had i',(":y),'"0/"1 in my definition
of mn. This did not accomplish anything useful for me. But,
hypothetically, if I had wanted to use the debugger on one of those
verbs this would have let me inspect x and y within an execution
instance.)
Anyways, to avoid fwrite and load, you could use 0!:0 (or, if you are
like me and wanted to see what was being executed, 0!:1 -- but you
could also use echo to display the script).
So, basically: you converted the input to literal J, using
instruction-at-a-time manipulation, and extracted the blocks as marked
by the inp statements. This is really nice, because it does not
require having inspected the code and taken advantage of the visible
regularities there. (Though it looks like you did take advantage of
the fact that w, x and y were irrelevant between these blocks...).
And then the other thing you did was form up the successive partially
formed serial numbers (in 'k' in your i0..i13 verbs) and when you
encountered multiple z values corresponding to different serial
numbers you pruned the intermediate results to either the maximum k
(>. mn) or minimum k (<. mn) for those z values, depending on which
part of the puzzle you were working on. And *that* is what makes this
work without running out of memory.
And, of course, like you mention -- <. mn and >.mn run to completion
right away because mn does not depend on y (nor x).
Really slick. (Though it does require enough analysis of the input
data to discard w, x and y between blocks or (equivalently) to realize
that z was the controlling value for every block and not just the
final block.)
Thanks!
--
Raul
On Thu, Jan 20, 2022 at 12:25 PM Stefan Baumann <ste...@bstr.at> wrote:
>
> Almost gave up on that one - but got it solved somehow and still don't know
> why it works...
> I started to parse the instructions into 14 iteration verbs i0-i13. For
> this I used a mapping m for translating instructions into J verbs - mapping
> inp to : is merely used for splitting; the jx verb then creates the
> corresponding J expression for the instructions which are eventually
> written to i, the J code to produce the iterations. I also wrote i to disc
> for inspection in a spreadsheet:
>
> m=: 'inp
> ';':';'-';'_';'add';'+';'mul';'*';'div';'<.@%';'mod';'|~';'eql';'='
> d=: >: i.9
> jx=: {{ ('[ ', >@(1&{), '=.', [: ; 1 0 2&{) <;._1 ' '&, y }}
> NB. i holds the J code for iteration verbs i0, i1,... ,i13
> i=: ,/"2 ([: jx@> [: |.@}. <;._2);._1 rplc&m fread 'xxiv.txt'
> i=: i,"1 '[ ''w x y z''=. |:y,.~0,.~d,.0 [ k=.d+10*x }}"0'
> # ". i=: i,~"1 (,&'=. {{ k,.z')@('i'&,)@":"0 i.#i
> 14
> 'xxiv.ijs' fwrite~ (,~ ,&LF)~/ i NB. Write i to disc for inspection
> 3681
>
> The maximum and minimum model number are then computed with the adverb mn -
> which takes >. and <. as a verb resp.- constructed from the J code stored
> in noun j. mn filters in 2 ways:
> 1. The verb dm calculates the distinct maximum/minimum. This was not enough
> - ran out of memory.
> 2. Then it appeared that z can only get smaller when it is divided by 26
> during the iteration and then it gets the same values as 2 iterations
> before. So in that case throw away all values larger than the maximum 2
> iterations ago, which is stored in q - p is the maximum of the previous
> iteration. Valid records are stored in r.
> This at least solved my puzzle input:
>
> NB. j holds the J code for the model number adverb mn
> j=: 'mn=: 1 : 0',LF
> j=: j, 'dm=. ([: ~. {:"1) ,.~ {:"1 u//. {."1',LF
> j=: j, '''q p''=. 0, >./ {:"1 r=. i0/ 0 0',LF
> j=: j, ; {{
> '''q p''=. p, >./ {:"1 r=. (#~ q>:{:"1)^:(0<[: I.&q {:"1)
> dm,/i',(":y),'/"1 r',LF
> }} &.> }.i.#i
> j=: j, '{., (#~ 0={:"1) r',LF ,')'
> {{ load y [ j fwrite y }} 'xxiv.ijs'
> >.mn NB. (*)
> 99394899891971
> <.mn NB. (**)
> 92171126131911
>
> I was puzzled that I had to write >.mn - first tried to use >.mn 0 - but
> that's probably due to y missing in mn's definition.
> What also didn't work was executing j with ". - is there a way of doing
> that without using fwrite and load?
>
> Resources used were quite small:
> timespacex '>.mn'
> 0.0939154 8786816
>
> Thanks. Stefan.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
