google trips中存在了280年的古老算法

简介: 本文翻译自https://research.googleblog.com/2016/09/the-280-year-old-algorithm-inside.html,文章描述了google trips中比较有意思的行程规划算法,供大家查看。 算法工程比较有意思的地方在于它永远不过时,不知道什么时候比较古老但是比较有用的算法可能会在我们的设计中体现,昨天,google发布了它的google

本文翻译自https://research.googleblog.com/2016/09/the-280-year-old-algorithm-inside.html,文章描述了google trips中比较有意思的行程规划算法,供大家查看。

算法工程比较有意思的地方在于它永远不过时,不知道什么时候比较古老但是比较有用的算法可能会在我们的设计中体现,昨天,google发布了它的google trips, 一个新的app帮助你创建你在城市中的非常不错的行程。而这个算法确实在280年之前就已经被论证过的。

1736年,欧拉发表了著名的有关柯尼斯堡的七座桥的著名论文,七座桥问题,如下:
image_01

在这篇论文中,欧拉研究了以下问题:能否旅行者所有桥只走一次就能够逛遍整所城市(大陆被七座桥隔开)?最后论文给出了结果,对于柯尼斯堡这个城市来说来说,不能。为了证明,欧拉提出了一种所谓的位置几何学的概念也就是后来发展出来的图论。论文中,所有的城市的大陆部分被桥分割称之为节点,而跨越大陆的桥则被称为边。如下图:

image_02

欧拉发现存在这种路径的充要条件是所有的节点都必须有偶数的边。只有在这种条件下,才存在一个穿越所有大陆连接,所有的桥只走一次;基于以上的发现,我们将它应用在了了google trips当中。

我们团队关于这种位置几何学的理论研究过了一阵子,后来我们的研究方向是根据欧拉的理论我们能否让旅行者尽可能的走边所有的地方,这种问题就是现在的“行程规划”问题。有关这种问题,欧拉没有研究过,但是基于欧拉的灵感,我们把它称为定向工程问题。

欧拉的解是完美的并且非常的正确,可是有关行程规划确实比较头痛,因为它不存在完美的解决方案,只能找到尽可能接近完美的解决方式。主要在于,有两个维度是有矛盾的地方:比如说要参观比较好的景点,但是时间的安排上确需要最节省;其次还需要考虑去的景点不要关门,要考虑到关门时间;甚至比如不要逛太多的博物馆(没人会喜欢连续的玩博物馆)。如此增加如此多的约束的问题都被归结为“旅行商”问题。

旅行规划的算法
幸运的是,我们有一个原则叫作三角不等原则,也就是任意两点之间增加一个路径点不会减少两点之间的距离。一旦潜在的这种路径存在并且遵从三角不等原则,我们的问题也就可以被另外一个算法去解决掉,这个算法是斯托菲季斯提出来的,这个问题分为四步做分解:

  1. 首先从所有的目的地出发,连接相邻的最近的两个点,也就是生成一颗最小生成树。
  2. 将最小连接数中的奇数点找出并连接上。这样就形成了所有的点的连接都是偶数点。(欧拉证明过只有并且所有的点都是偶数点连接才能够找到这样的路径)。

3.因为所有的的点都有偶数连接,形成了欧拉图,所以就有一个路径能被找到。

4.我们找大了路径,但是有可能有的路径是重复过的,没关系,将重复的路径只保留一条。于是我们就找到了这种最好的路径。

image_03

基于这种高效的路径寻找,我们可以很容易的一步就生成行程规划。在每一步中,我们预估用户最可能到的位置,并且用斯托菲季斯算法找出需要的时间消耗。更有,一个用户的的有关景点的选择基于景点的热门度以及相邻景点的差异(跟已经参观过的比较)。于是我们会选择最低的成本同时带来用户最大收益的景点作为路径点纳入进来。下面是伦敦的的几一个基于位置的路径规划选择过程:

image_04

google trips中的行程规划
基于我们在以上算法中取的的成果,我们跟google trips团队合作,我们意识到很难从头开始做,主要原因在于即便我们做了最好的行程规划算法,可是又的朋友说“这是很好的规划,但是我的朋友说另外一个地方也不要错过,同时我也只有上午有时间,可是我不想错过规划中的下午的景点,大本钟也已经去过两次了,没有兴趣了”, 所以基于以上的原则,考虑到用户的规划更多的是在飞行途中或者自己有时间才一点一点的做。同时很多的用户不一定在做规划的时候一定要连接网络设备,我们必须提供离线的行程规划解决方案。

最好的行程规划是基于群体智慧的
虽然在算法方面的挑战巨大,我门也意识到高质量的行程规划更多的依赖于用户对于我们行程规划的的路径点兴趣。即便是这样,我们从google的其他的地方得到了用户最喜欢的停留的地方,以及从一个地方到另外一个地方的时间(比如google map), 可是我们也无法知道对于我们规划的路线,用户是否真的喜欢。

于是我们将目光转向了群体的智慧,这些方式在google用来通常辨别高速的拥堵状况,以及餐馆的拥挤情况。我们用这些经验来应用到到行程中来让用户得到最好的体验。我们可以将我们已有的哪些景点比较受欢迎,跟旅行者在旅行中制定路线的选择联系起来。

这种群体的智慧会对未来会有极大的帮助,举例来说,我们观察发现,用户在11:30参观白金汉宫的停留时间比较长(相对于一天中的其它时间),刚开始有点不解,但是洗洗发现,停留时间长是因为在这个时间白金汉宫会有换岗的表演,会延长用户的观赏时间。我门也将这种时间维度的停留时间并入到我们行程规划的逻辑当中去了。

目录
相关文章
|
4月前
|
算法 vr&ar 图形学
☆打卡算法☆LeetCode 220. 存在重复元素 III 算法解析
☆打卡算法☆LeetCode 220. 存在重复元素 III 算法解析
|
4月前
|
算法 vr&ar 图形学
☆打卡算法☆LeetCode 219. 存在重复元素 II 算法解析
☆打卡算法☆LeetCode 219. 存在重复元素 II 算法解析
|
4月前
|
算法 vr&ar 图形学
☆打卡算法☆LeetCode 217. 存在重复元素 算法解析
☆打卡算法☆LeetCode 217. 存在重复元素 算法解析
|
6月前
|
算法 前端开发
前端算法-存在重复元素
前端算法-存在重复元素
|
2月前
|
缓存 算法 C++
C++古老算法介绍
C++古老算法介绍
|
4月前
|
算法
基于Google Earth Engine的Landsat单窗算法地表温度(LST)反演
基于Google Earth Engine的Landsat单窗算法地表温度(LST)反演
|
6月前
|
算法 测试技术 C#
C++算法:存在负权边的单源最短路径的原理和实现
C++算法:存在负权边的单源最短路径的原理和实现
|
10月前
|
存储 算法 前端开发
前端算法-查找是否存在重复元素
前端算法-查找是否存在重复元素
|
存储 算法 JavaScript
日拱算法:环形数组是否存在循环
存在一个不含 0 的 环形 数组 nums ,每个 nums[i] 都表示位于下标 i 的角色应该向前或向后移动的下标个数: 如果 nums[i] 是正数,向前(下标递增方向)移动 |nums[i]| 步 如果 nums[i] 是负数,向后(下标递减方向)移动 |nums[i]| 步
|
存储 机器学习/深度学习 人工智能
关于哈密顿路是否存在的遍历算法
我是怎么也没想到这个问题陪伴了我快十年的时光,占到了我生命的一半时光(当然不可能一直在死磕这道题),十年中每每学到一些新的知识都会进行一些尝试,但很多时候还是无功而返,大概在十天前复习数据结构相关知识的时候偶然发现了一个简单而且有趣的公式,然后灵感就来了,不过有一点点遗憾的是身为学数学的出身的,未能使用纯数学的方式解决,有一点点丢人,话不多说,请看正文。
100 0
关于哈密顿路是否存在的遍历算法

热门文章

最新文章