【发布时间】：2015-08-14 19:59:33
【问题描述】：
我正在尝试编写一个 Java 程序，以找到最好的路线，以便在美国职业棒球大联盟的 30 个体育场中的每一个体育场进行驾车游览。我使用公制 Miles Driven + (200 * Number of Days on the Road) 来定义“最佳”行程；这消除了 30 天内 20,000 英里或 90 天内 11,000 英里的旅行，这两种旅行都不是我想参加的旅行。每支球队在 183 天的赛季中打了 81 场主场比赛，因此需要考虑球队何时在家。
另外，我不只是在寻找整个棒球赛季的最佳巡回赛。我正在寻找在任何特定日期（6 月 15 日底特律，8 月 3 日亚特兰大等）在任何特定 MLB 城市开始/结束的最佳巡回赛。
我的程序产生了令我非常满意的结果，但是在我的笔记本电脑上运行需要几个月才能完成，我想知道是否有人对如何使它更高效。
程序迭代运行。它从一个游戏开始；比如说，4 月 5 日的芝加哥。它会计算出你可以在芝加哥比赛后的一两天内参加下一场比赛；假设在辛辛那提和底特律有两场这样的比赛。它创建了一个数据结构，其中包含每次预期旅行的所有站点（一个用于芝加哥-辛辛那提，一个用于芝加哥-底特律）。然后，它会为两个 2 站游览找到预期的第 3 站，依此类推，直到到达第 30 站和最后一站，此时它确定最佳游览。
它使用几种方法来修剪低效的旅行。主要的是使用 HashMap。关键是一个字符序列，它表示（1）哪些球场已经被访问过，（2）这是最后一个访问过的球场。所以它会在 A-B-C-D-E 和 A-D-B-C-E 上遇到重复。然后它将保留较短的路线并消除较长的路线。对于大多数起点，这使列表中的最大旅行数量在任何给定时间保持在 2000 万左右，但对于某些起点，它会达到 9000 万左右。
那么……有什么想法吗？
【问题讨论】：
-
另外，如果你想知道我到底需要这样的东西来做什么，它是我作为爱好做的可搜索数据库网站（bestballparktour.com，如果你'感兴趣）。我现在加载的数据集，我不满意；我走的捷径太多，如果您查阅 MLB 赛程表，在很多情况下您可以找到更好的旅行。另外，我知道该网站看起来不是很吸引人；我不是一个真正的网络程序员。修复数据库后，我可能会尝试让它看起来更时髦。
-
你熟悉A*（A星）算法吗？老实说，我不是 100% 熟悉你的问题的领域，但在我看来，你应该能够为 A* 定义一个估计指标，这将大大提高你的效率，而不是像你这样的天真的广度优先搜索正在做。
-
如果下一跳在几天或英里或每天英里内太长，我会说不要处理给定的旅行。你说过 20k 英里超过 30 天，这是平均每天 600 英里，如果开车 8 小时是 80 英里/小时 - 是不是太快了？因此，设置一个阈值“太远”、“太晚”、“太快”，如果一跳超过其中之一，则放弃游览。 （我想说这些门槛是可选的，因为有些人更喜欢从东海岸到西海岸的单程旅行，如果所有其他旅行都相当短的话。）
-
@DiegoMartinoia 这里 A* 实现的问题是 A* 通常受搜索空间的限制，而这里假设所有体育场之间的完整图，并且节点之间的距离也随时间变化。假设两个相邻的体育场A和B在今天和明天举办比赛，那么A在一周后举办比赛，B在两周后举办比赛，AB距离提前1天和2周后，而BA距离提前一周，迟到未知。所以我认为这里根本无法实现A*。
-
@Vesper ，我认为我们可以将图中的节点表示为位置+时间对（即一个节点 == 一场比赛），这样您的所有距离都是明确定义的（回去在时间 == 无限距离）。但是，再一次，我可能没有完全理解这个问题。