Getting Deeper (and Broader) with Graph Algorithms

https://i.stack.imgur.com/KspsC.png 

After spending some time on Leetcode, I got bored of repetitive drilling.  I wanted to keep learning and decided to dive deeper into Graph Algorithms.  I find Graph Algorithms particularly appealing because most if not all problems can be modeled using Graphs.  As such, mastery of canonical Graph Algorithms should prove generally useful long term.

I picked up a book on graph theory as a primer. However, as I looked around for resources on applied computer science algorithms I found that there wasn't much out there.

Based on what I'd seen on Leetcode and read in Needham and Hodlers' "Graph Algorithms" book (mostly a users guide to Neo4J), I took it upon myself to collate a brief collection of graph algorithms for self use.  The exercise has been rewarding.  The code is mostly intended as a learning tool.

If you're at all interested in Graph Algorithms, by all means check it out.



Comments

Post a Comment

Popular posts from this blog

Engineering Truisms

This is a brief collection of quotes, laws, and truisms that I've gathered over the years.  I've kept those that have consistently proved themselves across organizations and projects during my career.
Read more

The Telescoping Constructor (Anti-Pattern)

Image
The Telescoping Constructor Looks like this: Widget(varA) {...} Widget(varA, varB) {...} Widget(varA, varB, varC) {...} or Widget widget = new Widget(x); widget.setVarA(...) widget.setVarB(...) widget.setVarC(...) There are both shared and specific problems for each variety.  Let's talk about both. The 1st case, supernumerary constructors. What's wrong with this? Well, the good news is you provide  quiet consumption since there's a bespoke constructor for every use case.  Rather than have noisy construction, where the consumer must fill in a bunch of nulls, you move the noise into the implementation.  We shouldn't make assumptions on how many times the class will be used, so keeping the complexity to ourselves is generous and will lead to a more maintainable macro system. However, one problem here is that the end consumer is not restricted in their choice of constructors.  Like shopping at the super ...
Read more

Software Capex: The Cost of Flexibility

We tend to think of flexibility as a good thing.  When it comes to interpersonal relationships, the ability to compromise is considered a sign of maturity.  Shouldn't this be the case for software?  After all, software is just a human solution to a human problem. Well, it turns out that it depends on what exactly we mean by "flexibility."   Flexibility as software extensibility is generally positive.  It's unlikely that we perfectly capture the problem space in an optimal fashion in the first go.  We should strive to make our future selves' lives easier.  Extensibility means, holding all else equal, building a version of the solution that is easier to expand upon in the future.  This kind of flexibility is good.  It means spending a little extra time now to save time in an ongoing fashion in the future.  We'll return to this idea later.   When by "flexibility" we mean producing a solution to an ambiguously defined problem, that's wh...
Read more