in reply to Re^8: nesting loops help?
in thread nesting loops help?

I just am not sure which part I'm not adequately explaining

You tell us in great detail what you are doing to solve some problem you haven't told us anything about. I can't really evaluate your logic because I have no context for it - there is no big picture to provide that context.

I don't want any more "how", I want "why". For example, this is the first time you tell us the yes/no column isn't important: it is related to some version of "how". If we had some "why" we could then understand we were free to ignore the yes/no stuff.

In general don't think in terms of file lines, think in terms of related data and how you might best store that for later testing. In this case it looks like you want to know what set of schedules a particular actor was involved in. That information is contained in records in the schedules file so you need to parse those records. Look back at my last sample code with that in mind and see where it gets you.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Replies are listed 'Best First'.
Re^10: nesting loops help?
by shadowfox (Beadle) on Mar 15, 2022 at 02:12 UTC
    Perl isn't really my foray yet, but I've been solving technical challenges my entire life and the why rarely ever matters. The solution comes from using the right functions in the right spot to get the right output, I've provided the inputs, the outputs and attempts to get to the goal that didn't quite work to show the track I'm working on, I didn't add unnecessary detail about other things because they weren't part of the problem so as not to distract away from areas that matter. The middle column (yes/no) function adds a quick visual check to assist with working out the third. If I end up with a schedule name in the third column where that line in the second says no, I already know I messed up because its the wrong result being retrieved. I said it didn't matter to the final solution because once I have that I won't need it, but it definitely makes getting there easier to troubleshoot.

    I'll keep working on it, I toyed around with the last suggestion but it's not quite there and I don't yet see what should be so I'm playing around with different ways of recalling previously stored data while iterating a loop of a different data source.

      I apologize for following a thread of conversation that seems to be getting more and more off the original topic and, seemingly, away from being helpful, but I think there is an important point here that is worth exploring just a little further.

      I've been solving technical challenges my entire life and the why rarely ever matters

      I would make the same statement except that I'd say the "why" is almost always critical to a good solution. Knowing the why drives the problem solving process in a direction that gives a best solution for the problem at hand in the current context. A silly example: you are driving a car and get a puncture. You could:

      1. Change the wheel for a spare wheel
      2. Call road-side service
      3. Flag a taxi
      4. Drive on the flat and destroy the wheel

      Without context, without a "why", there is no sensible way to pick the best option. If you are in no particular hurry any of the first three look OK. If you are dressed to the nines for a dance, changing the wheel yourself is probably off the table. If you are five minutes from the airport and must catch a plane, maybe destroying the wheel is the only option, or maybe calling for a helicopter pickup is the thing that makes sense - even though that solution isn't in the list.

      Knowing the "why" can allow options that a narrow problem statement misses. In the current thread there is lots of "how do I solve this problem", but no context to help us understand the big picture problem, or even to appreciate the immediate problem that is hinted at.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond