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
