On Wed, Dec 14, 2022 at 2:26 AM Jaume <greenni...@gmail.com> wrote: > Because somewhere in there something broke and on the phone I have the > wrong answer for part 1.
Yes... generally it's easier to debug if you have a much smaller implementation. It's also a *lot* easier if you write your code so that you can test against the sample data posted in the puzzle description. (I always set up two values, one represents the input.txt dataset, the other represents the sample data. If the puzzle has several sets of sample data, I add additional variables holding each of those values. This way, I can test my code, and see that it generates the right result for the test case(s) they provide.) So in my puzzle implementation, I have something like this: input=: fread '~/Downloads/input.txt' sample=: {{)n [1,1,3,1,1] [1,1,5,1,1] [[1],[2,3,4]] [[1],4] }} Of course, my sample value is longer than that -- 23 lines instead of five lines, but this should give you an idea. Also... for what it's worth, here's an example of how you might parse the data set for that puzzle: with=: ,&boxxopen&.> rpl=: rplc <@rplc&('\n';LF;'\$';EAV);._2 xlate=: rpl&'with )/)/'@rpl&'[/(<a:with /]/)/,/ with /\n\n/\n\$/' parse=: {{".;._2;._2 xlate y,LF }} Here, with the above definition of sample, the phrase parse sample would give me a 2 row 2 column matrix. With the full sample dataset from the website, it would give me an 8 row matrix (still 2 columns wide). You can get an idea of what's happening here using xlate on the text of the sample. Here's a short form: xlate '[1,1,3,1,1]' (<a:with 1 with 1 with 3 with 1 with 1) That's a sentence which can be executed: (<a:with 1 with 1 with 3 with 1 with 1) +-------------+ |+-----------+| ||+-+-+-+-+-+|| |||1|1|3|1|1||| ||+-+-+-+-+-+|| |+-----------+| +-------------+ In other words, each bracket pair in the original becomes a parenthesis pair, with the text in between changed so that it will give a J representation of the described data structure. There's an extra unnecessary level of nesting in the result, but that's not really a problem. For part A, my solution looks like A=: {{+/1+I.1=,compare/"1 parse y}} And, with the full sample from the web site: A sample 13 So, in my implementation I have down at the bottom assert 13=A sample So I can immediately confirm, when loading the script, whether I've made any major mistakes. (And I frequently make mistakes, so that's a great time saver.) (Also... my compare is rather small., though hypothetically speaking it could be much smaller if I used a different parser. In my compare, I used nested if statements and recursion to compare. However, conceptually, if I had parsed the text of the problem differently -- forcing each number to be nested to the same depth, for example, I might be able to use J's built-in sort instead -- see https://www.jsoftware.com/papers/TAOaxioms.htm for more details on why it might be possible to use, for example, the lt and gt from https://code.jsoftware.com/wiki/Essays/The_TAO_of_J to define compare=: lt - gt) FYI, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm