Combine functions to decrease complexity

[arav-agarwal2]

• [x] Graph-Search
• [x] Shortest Path
• [x] MinimumSpanningTree
• [x] MaxFlow
• [x] MinCostFlow
• [x] MinCut
• [x] MinMeanCycle
• [x] Matching
• [x] Connectivity Algorithms
  • [x] TopologicalSort
  • [x] CheckedTopologicalSort
  • [x] Bipartite Partitions
  • [x] loopfree
  • [x] parallelfree
  • [x] simpleGraph
  • [x] eulerian
• [x] PlanarEmbedding and Drawing
  • [x] PlanarEmbedding
  • [x] PlanarDrawing
  • [x] PlanarColoring
• [x] TSP
• [x] Approximation Algorithms

[josherrickson]

Related to this, I think we should not export any ___Runner functions. Hoepfully most of them will be combined per this issue; if any algorithms don't fall into this category (e.g. only a single algorithm so nothing to combine), let's either

a) rename ____Runner to remove "Runner", or b) Create a simple wrapper similar to the combined functions that has no algorithm argument (or, future-proofing, has an algorithm argument that only takes one valid entry right now).

I strongly prefer b), just to create a consistent separation between ____Runner, which are direct access to the RCpp functions, and ____ which are our R interfaces.

The currently exported Runners are:

export(BellmanFordRunner)
export(BfsRunner)
export(CirculationRunner)
export(DijkstraRunner)
export(GomoryHuTreeRunner)
export(GrossoLocatelliPullanMcRunner)
export(HaoOrlinRunner)
export(NagamochiIbarakiRunner)
export(PlanarCheckingRunner)
export(PlanarColoringRunner)
export(PlanarDrawingRunner)
export(PlanarEmbeddingRunner)
export(SuurballeRunner)

[josherrickson]

The more I think about it, the more I like the idea of all wrapper functions having an algorithm argument, even if on some functions there is only a single valid algorithm implemented right now.

[arav-agarwal2]

I agree with this - it sounds like a decent way to handle everything, and makes the interfaces easier to parse for the R developer using it.