Closed jakobbossek closed 9 years ago
We need to tackle some problems in this context.
concorde_path
function of the TSP package as an example). Since this seems to be very restrictive and redundant the runSolver
function should also look in the current working directory and in the R options for the solvers.All of these solvers are open source, we could ship the source and compile them when the package is installed (this is not violating CRAN guidelines).
We could simply include the code, compile it and use its current interface which requires the tsp instance to be stored in a file. But this interface is ugly. It would be nice to pass a Network instance (instead of a file path) to the solver and solve it directly, but this would require a lot of code adaptions of LKH / EAX.
How about "storing" the network temporarily in a file and then access it via the solver?! Would not be the best solution, but maybe a work-around without adapting the solvers itself.
Yeah, this is a very ugly workaround. In the worst case this would require two imports of the same instance. I don't like it, but this is the way it is solved now :sweat_smile:
Going to finish this within the next two weeks.
Closing this. Solver interface is implemented. It needs some more features, which are covered by other issues. We can now pass either a network or a path to an instance in tsplib format.
Hi there! I've just discovered this package and it looks great. But, where can I find the binaries of EAX-restart?
A basic implementation already exists in our TSP repository. Integrate it and find an easy way for the user to set the path(s) to the binaries of the solvers.