In particular I failed to realize that the optimal step might not be
unique. Before I boxed
p=. p,<i#DIRS
the example problem returned 4 instead of 3. All solutions are appended to
path, and the tail is chosen by
i=. (=<./)|position-,h+/{:path
The program worked by good luck rather than through my comprehension. The
length of p is correct, and the length of path is wrong, and could be fixed by
choosing only one of i .
Thank you.
Date: Mon, 18 Dec 2017 09:07:52 -0500
From: Raul Miller<[email protected]>
To: Programming forum<[email protected]>
Subject: Re: [Jprogramming] AoC Day 11 - something is wrong
Message-ID:
<CAD2jOU8yqDZKd=d42v_aba3owv+31ueo00bft_hd-lgny+a...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
If I read this right it works like this:
(a) Use complex numbers to represent x,y coordinates
(b) Find the location of the end of the path
(c) Trace a path from the start to that location, by repeatedly
picking a step that gets closer to that location.
This works great for part 1, but is inefficient for part 2 (where you
must find the greatest number of steps needed to reach any point along
the path).
That said, if you don't mind the wait, the inefficiency for part 2 is
not a blocker.
Thanks,
-- Raul On Mon, Dec 18, 2017 at 8:18 AM, David Lambert
<[email protected]> wrote:
This step counting verb uses lengths of equilateral hexagonal grid, taking
that step or apparently quantum tunneling pair of optimal steps. I have not
tried to understand it, but it works.
DIRS=:;:a=:'ne n nw sw s se'
('a'~)=. 1ad30 1ad90 1ad150 1ad210 1ad270 1ad330
count_steps=: 3 :0
position=. +/(". ::])y
h=. ne,n,nw,sw,s,se
path=. 0j0
p=. 0$<''
while. 0.2<|position-{:path do.
i=. (=<./)|position-,h+/{:path
path=.path,({:path)+h#~i
p=. p,<i#DIRS
end.
(;~#)p
)
count_steps se,sw,se,sw,sw
┌─┬───┬──────┬────┐
│3│┌─┐│┌──┬─┐│┌──┐│
│ ││s│││sw│s│││sw││
│ │└─┘│└──┴─┘│└──┘│
└─┴───┴──────┴────┘
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
