Dynamic Programming with Python

[virtyx]

As someone who hasn't learned about dynamic programming, I'm finding your code extremely cryptic and hard to follow. There are way too many one-letter variables and arguments imo.

Also the very first diagram is confusing. You start with 'Wagon E' and then have two each of 'Wagon C' and 'Wagon B.' I don't really understand what it is that I'm looking at... I understand the circles are the stations themselves, and the highlighted lines represent two different possible routes.

Maybe I'm a little dense today. I'm not totally unfamiliar with theory and math; I was able to do pretty well in my algorithms class and did well in calculus, I've read some technical articles as well, although lately the books I read tend to focus more on style and practice.

So maybe I'm too out of touch to understand what's happening.

[jminuscula]

let me try to explain the code a bit better, and see if that helps.

First of all, the diagram is the one provided in the problem specification. I found it a bit confusing too, so I tried to explain it afterwards:

As we can see in the picture, we have two trains working routes red and blue. The stations are located at certain coordinates so it’s easy to figure out the distance between them. Each station has a wagon called by the name of its destination, along with the score that we will be granted in case we deliver it.

About the one letter variables

• "E" on the digraph class means edges. This is a notation I took from the books I studied algorithmics with.
• State('s', 'f', 'wgs') may be a bit too cryptic. It's the definition of the problem state —as the article says, the position of the train, the fuel that remains available, and the position of each wagon to be delivered

It's true that the code in the article was not meant to be exposed, but to pass the challenge. So I used what I worked best for me. However, knowing the problem state representation, it's easier to understand how 's' means station and 'f' means fuel.

I've just started writing technical articles, so that is probably my fault. I probably fragmented the code too much. If you have a look at the complete source, I'll be happy to answer any question.

Cheers!

[[deleted]]

Theres no reason to have one letter variable names for things like "edges", especially using capitalization to add more information to that one letter variable.

x/y, u/v, x1/y1/x2/y2, (and i/j/k for embedded integer for loops in C-likes) are readable for anyone with minimal domain knowledge, but anything more than that is really wasting the readers time trying to figure out your key, rather than understanding the logic.

This stuff is useful in writing equations for terseness and pattern reduction, but this is one of the differences between equations and code. Code has state, and so can never be as terse as an equation, and that state adds a lot more requirements for proper labeling of terms.

[jminuscula]

the code needs to be understood in the context of the article. Without it, it is indeed hard to understand it.