Here's how I would interpret the final stage's result:

dss=:-:<:3 #.inv 15 21 19 11 5 7
nms=: ;:'n ne se s sw nw'
location=:3 :0
  {:+/||:+/\dss{~nms i.y
)

This translates a symbolic sequence into a grid location. So as a
basic integrity check, I would run it against both your source
sequence and your result sequence. If the location of both is the
same, you are probably on the right track.

But I think this problem requires at least two passes. If you do not
figure out where you are going before you try to find the shortest way
to get there, you wind up trying to find the shortest distance to
"everywhere". (And, ok, that can be a quicky description of a viable
algorithm, but you still wind up with multiple passes of a sort in
your implementation.)

Thanks,

-- 
Raul


On Sun, Dec 17, 2017 at 11:06 AM, Brian Schott <[email protected]> wrote:
> All, not just Raul and Jimmy,
>
> I have chosen to reply to this earlier email because it contains
> the "first attempt" solution I previously posted. That solution
> ends inconclusively and created too many posts from me. However,
> those posts and especially Raul's guidance have led to another
> level of completeness. So "bear with ...":
>
> The result from before is captured in the noun `test` which
> contains 939 steps from my initial data which contained
> 16445 steps.
>
> Recall that test was developed using the following expression.
>
>      test =: ((all :: ])&. ;:)^: _ blah blah data
>
> The error was detected finally by removing the :: ] from
> the attempted continuation, as shown next.
>
>     ((all )&. ;:)^: _ test
> |index error: ne0
> |       ((all)&.;:)^:_ test
>
> The error in ne0 occurred because only NE,N, and S remain in the
> nub of the iterative process, and nei, the feeder verb to neo,
> feeds nei an index of 939, which is too big (by 1, of course).
>
> Presently my correction is to repeat the iterative process on the
> completed process with 3 changes shown next.
>
>    test  =: ((all :: ])&. ;:)^:        _   blah blah data
>    test2 =: ((all :: (1&|.)@])&. ;:)^: 939           test
>
> The changes are detailed as follows.
> 0) :: ]  is replaced by :: (1&|.)@]
> 1)   _           is  replaced by 939 which is #;:test
> 2) RHA of blah blah data is replaced by test
>
> The good news is that the result is better but not completely
> fool proof. The results show (below) that the reduced total
> number of steps is 806, of which the 696 NE steps are all that
> matter because the 110 N steps are redundant. You can visualize
> that they are redundant by recognizing they are not cumulative;
> rather think of them instead as alternatives, where they BOTH
> begin at the initial position, sort of. (That's not a very
> good explanation. Please help me.)
>
>    #;:test2
> 806
>    ~.;:test2
> ┌──┬─┐
> │NE│N│
> └──┴─┘
>    #/.~ ;:test2
> 696 110
>
> The bad news is first of all that the kind of phony interpretation
> that I gave is required, and the results were only achieved by
> dummying up the second iterative step to have a finite repetition
> limit.
>
> a) Can anyone think of a better way to avoid the requirement of a
> second iterative step?
> b) Can anyone give a better and more general explanation of how to
> interpret and explain the final stage's result?
>
>
> On Sat, Dec 16, 2017 at 2:32 PM, Brian Schott <[email protected]>
> wrote:
>
>> I have completed a first attempt at implementing Jimmy's
>> ideas of parsing the symbolic list of directional moves.
>> With Raul's help in making the tacit agenda code work, I
>> put together the following J calculations. The main verb
>> below is `all` and applying it iteratively to the data
>> list, I put the result in the noun `test` for further
>> analysis.
>>
>> As you can see test contains 939 directions, so further
>> processing is required. Please see below for further
>> comments.
>>
>>
>>    #;:test =: ((all :: ])&. ;:)^: _ toupper data rplc ',';' '
>> 939           NB. if data includes an ending LF, use }: also
>>    ~.;: test
>> ┌──┬─┬──┐
>> │NE│N│SE│
>> └──┴─┴──┘
>>    15{.;: test      NB. just to explore
>> ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
>> │NE│NE│NE│NE│NE│NE│NE│NE│NE│NE│NE│NE│NE│NE│NE│
>> └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
>>    _15{.;: test     NB. more exploring
>> ┌──┬──┬─┬──┬──┬──┬──┬──┬──┬─┬─┬─┬─┬──┬─┐
>> │NE│NE│N│SE│SE│NE│NE│SE│SE│N│N│N│N│NE│N│
>> └──┴──┴─┴──┴──┴──┴──┴──┴──┴─┴─┴─┴─┴──┴─┘
>>    #/.~ ;:test
>> 563 243 133          NB. NEs,Ns,SEs ; see nub next
>>    ~.;: test
>> ┌──┬─┬──┐
>> │NE│N│SE│
>> └──┴─┴──┘
>>    +/563 133 110      NB. used because 243>133 => 133 more NEs
>> 806
>>    +/\563 133 110     NB. looking again at cumulatives
>> 563 696 806
>>
>> NB.  BINGO, that 696 was the correct answer for my data
>> NB.  because 563+133 NEs  "erase" the remaining 110 Ns
>>
>> So, this approach is enlightening, but I am not
>> clear on how to generalize on the post-processing
>> analysis, or how to change the processing to eliminate
>> the need for the post-processing analysis.
>>
>> I'll attempt to supply the code needed below.
>> The data may be different for each person on AoC, I'm not sure.
>>
>> swi =: [:(<./,]i.<./)(;:'NE SE N') i.~ ]
>> sw0 =: a:-.~(a:"_)`(0,{.@[)`]}
>> sw1 =: a:-.~(('S';a:)"_)`(0,{.@[)`]}
>> sw2 =: a:-.~(('NW';a:)"_)`(0,{.@[)`]}
>> swa =: ({.@] sw0 [)`({.@] sw1 [)`({.@] sw2 [)@.({:@] ) swi
>>
>> nwi =: [:(<./,]i.<./)(;:'SE NE S') i.~ ]
>> nw0 =: a:-.~(a:"_)`(0,{.@[)`]}
>> nw1 =: a:-.~(('N';a:)"_)`(0,{.@[)`]}
>> nw2 =: a:-.~(('SW';a:)"_)`(0,{.@[)`]}
>> nwa =: ({.@] nw0 [)`({.@] nw1 [)`({.@] nw2 [)@.({:@] ) nwi
>>
>> sei =: [:(<./,]i.<./)(;:'NW SW N') i.~ ]
>> se0 =: a:-.~(a:"_)`(0,{.@[)`]}
>> se1 =: a:-.~(('S';a:)"_)`(0,{.@[)`]}
>> se2 =: a:-.~(('NE';a:)"_)`(0,{.@[)`]}
>> sea =: ({.@] se0 [)`({.@] se1 [)`({.@] se2 [)@.({:@] ) sei
>>
>> nei =: [:(<./,]i.<./)(;:'SW NW S') i.~ ]
>> ne0 =: a:-.~(a:"_)`(0,{.@[)`]}
>> ne1 =: a:-.~(('N';a:)"_)`(0,{.@[)`]}
>> ne2 =: a:-.~(('SE';a:)"_)`(0,{.@[)`]}
>> nea =: ({.@] ne0 [)`({.@] ne1 [)`({.@] ne2 [)@.({:@] ) nei
>>
>> ni =: [:(<./,]i.<./)(;:'S SE SW') i.~ ]
>> n0 =: a:-.~(a:"_)`(0,{.@[)`]}
>> n1 =: a:-.~(('NE';a:)"_)`(0,{.@[)`]}
>> n2 =: a:-.~(('NW';a:)"_)`(0,{.@[)`]}
>> na =: ({.@] n0 [)`({.@] n1 [)`({.@] n2 [)@.({:@] ) ni
>>
>> si =: [:(<./,]i.<./)(;:'N SE SW') i.~ ]
>> s0 =: a:-.~(a:"_)`(0,{.@[)`]}
>> s1 =: a:-.~(('SE';a:)"_)`(0,{.@[)`]}
>> s2 =: a:-.~(('SW';a:)"_)`(0,{.@[)`]}
>> sa =: ({.@] s0 [)`({.@] s1 [)`({.@] s2 [)@.({:@] ) si
>>
>> all =: na`sa`nea`sea`nwa`swa@.(dirs@{.)
>> dirs =: (;:'N S NE SE NW SW')&i.
>>
>>
>> If you've gotten this far, you may be interested in an
>> anomaly that turned up when further analyzing the results
>> in `test`: i. could NOT locate the first <'N' in test,
>> although i. successfully found the other 2 nub elements.
>>
>>    #;:test2 =: ((all :: ])&. ;:)^: _ test
>> 939
>>    (<'NE') i.~;: test
>> 0
>>    (<'SE') i.~;: test
>> 649
>>    (<'N') i.~;: test       NB. this result should be < 939
>> 939
>>
>
>
>
> --
> (B=) <-----my sig
> Brian Schott
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to