This, I think, and to my annoyance was the easiest so far. It took me a couple of goes to get it right and there was a lot of head scratching as I just couldn’t see why it was coming out with a figure which was way too low.
Each time I had an ‘aha’ moment, like re-reading the actual problem and realising you had to go back to the beginning of the directions if the destination hadn’t been reached, I came across a different issue. In the end it was all of my own making, trying to be cute with the data input strings and messing them up.
The solution was much, much more simple and more elegant than I originally coded and I did it all with just one outer and one inner loop.
The input data, as in other problems, was pasted into Visual Studio Code, but manipulated a little by making all the directions into 1 character strings in an array.
The nodes were simply strings of 9 chars each in another, larger array.
Once the data was in, a function was created to find the next node for any given direction and position.
And the main logic was an outer and inner loop which cycled through each direction letter, L or R, and called the nextnode function to get the next string which needed to be searched for.
I got lost a little when it wasn’t returning a number large enough by convincing myself I had to start at position 0 on the array as (I thought) it was only the example given that started at AAA. I was very wrong about that! So, obviously the first thing to do before starting the main loop was to find the correct starting position.
So there we are – after greatly simplifying the input strings, and getting rid of the 3 (yes 3) extra loops I thought I needed, as well as exiting the inner FOR loop early for efficiency, I got the processing time down to about 2 hours and, at last, arrived at the correct number.
As the problems become more complex now, and the input data is getting huge, I may end up using a different language to solve the rest. However, if I can, and if the input data is small enough, I will at least try every one possible. Or, and I think I prefer this, I might reduce the data to at least show the logic on a C64 can work. So I will potentially base these articles on the example data, and use C# (maybe) for the actual answers.