The Traveling Salesmen Project

Perhaps the entire point of the traveling salesman problem is to preform the problem on a map of an incredibly large size. As much as we would have liked to, we did not have enough time to create, much less test, a map of more then fifteen points. Most practical situations would require many more points then we tested, however, we have faith in our algorithm. We were unable to test it on a map of incredibly large scale, so the scalability of the program is untested.

Making an application scale is perhaps one of the most difficult things for a programmer to do. What is faster on a ten point map might not be faster for a hundred point map. The correct method for all sizes of maps is probably unachievable, so the program should modify its algorithm based on the number of points in a map.

Another essential aspect of a map is change: traffic changes, storms can occur and volcanoes erupt. For example, a mars rover might have to go from Colored Chaos to the Sabis Vallies, but a storm will reach the path between the Mars 2 Lander and the Mars 6 Lander in an hour. Therefore, the model must take into account that the weight of a route might change over time.

Of course, our entire model has yet to be implemented completely into a single practical situation. Next year, our team will try to tackle the problem of passing period... Getting from one point to another within the ten minutes given. We will have to use a dynamic map file, as well as a large map file. Acquiring the resources to run the application will force us to dive into LISP and discover its methods for multi-processing.