从《天行九歌》到海盗问题

2024-04-03 00:32
文章标签 问题 海盗 天行 九歌

本文主要是介绍从《天行九歌》到海盗问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

阅读本篇文章大约花费您8分钟!


今天和大家一起思考一道博弈题:海盗问题。

提出海盗问题

在国产动画《天行九歌》中,有这样一个场景:在鬼兵盗窃军饷后,公子韩非深入将军府,与大将军姬无夜展开了一场精彩绝伦的对弈,其中涉及到一个分金币的游戏,游戏规则如下:

图片中提到的游戏实际上是一道博弈题:海盗问题。分金币是一种变种而已,本质是不变的。题目的一种解法已经在图片中显示出来了。关于海盗问题如何体现在《天行九歌》中,大家可以自行去看正片(我本身是国漫迷,所以我在这里推荐大家有空去看一看,再有这一段确实非常精彩,对于理解海盗问题有很大的帮助)。

下面我们就来分析一下海盗问题。

海盗问题的描述

有5个海盗,获得了100枚金币,于是他们商量一个方法来分配金币,分配的方法如下:

  • 由5个海盗轮流提出分配方案
  • 如果超过半数(包括提出者)的海盗同意方案,按照此方案分配
  • 否则,则提出者被扔到海里喂鱼,剩下的海盗继续商量
  • 海盗绝对理性,即以自己尽可能多获得金币为目的,但是在收益相同的情况下,会有倾向的把提出者喂鱼

提问:第一个海盗应该如何提出分配方法,才能保证自己不被喂鱼并且利益最大化?

海盗问题的解决方案

假设有5个海盗A,B,C,D,E

 

假设A提出方案:A(100),B(0),C(0),D(0),E(0),这种情况下,B,C,D,E毫无疑问会一致反对,反对人数超过半,A会被喂鱼。然后继续分配。

假设B提出方案:B(1),C(33),D(33),E(33),假设此时C反对,其他都同意,此时同意人数超半数,会按照这个方法分配。

 

下面我们回到问题本身,第一个海盗A应该如何提出方案?

如果方案是A(0),B(25),C(25),D(25),E(25),这样A是安全的,但是并没有达到利益最大化。

如果方案是A(20),B(20),C(20),D(20),E(20),这样A仍然没有达到利益最大化。

……

对于海盗问题,我们可以使用递归的思想进行分析,前一个海盗的分配方案需要参考后一个海盗的最优情况,只需要在后一个海盗的基础上增加一点点金币就可以了。因此A在分配时会考虑如果没有A,B的最优情况。B在分配时会考虑如果没有B,C的最优情况…以此类推,通过递归的思想,我们需要首先分析只有DE两个海盗时D的分配方案:

      

       对于D而言,无论D提出什么样的方案,E都可以不同意,由于只有两人,只要E不同意,D一定会被喂鱼,所以对D来说,没有任何选择。

       对于C而言,由于D没有任何选择,所以无论C提出什么方案,D一定会同意(否则D被喂鱼),E一定不同意。此时C(100),D(0),E(0)。

       对于B而言,C的最优策略是100个金币,因此C为了获得100金币,一定不会同意B的方案,这是B只需要给DE各1个金币,这比C提出的方案要多一个金币,所以DE一定会同意,此时3人同意,B(98),C(0),D(1),E(1)。

       对于A而言,B的最优策略是98个金币,B为了获得98个金币,必然不会同意A的任何方案,此时有5人,最直接的方式是A需要再说服两人同意他的方案。C再B方案下是0个金币,因此A只需要给C1个金币,C一定会同意,原来DE各1各金币,A只需要获得其中一人的支持给他2个金币即可,因此,A的方案有两个:A(97),B(0),C(1),D(2),E(0)或者A(97),B(0),C(1),D(0),E(2)。这就是海盗问题的答案,A提出这两种方案时,不会被喂鱼并且利益最大化。

天行九歌中的海盗问题

在引言中提到,天行九歌中也存在这样的问题,只不过在动画中,分金币的是三个美人。

通过上面的分析,对于3人分100金币的问题应该不难回答,第一个美人为了保住性命,会参考第二个美人的策略,由于第二个美人没有任何选择,因此,第一个美人只需要给第二个美人1个金币,第二个美人一定会同意,此时达成2:1的局面,第一个美人获得99金币,这是在动画中的分配方案:

第一个美人

第二个美人

第三个美人

99

1

0

在动画中,公子韩非提出了这样的分配方案,然而大将军姬无夜随即拔刀指向第一个美人,第一个美人立即下跪求饶,并指明一个金币也不要了。随后姬无夜说到强者随时可以改变规则,而弱者根本没有资格来制定规则。

其实通过上面的分析,我们可以知道99金币并不是第一个美人的最优方案,哪怕第一个美人拿走100金币,第二个美人也必须同意,否则,如果只剩两人的话,第二个美人一定会被处死。所以100个金币才是第一个美人的最优策略。

海盗问题还可以继续扩展,比如7个海盗分100金币,第一个海盗可以提出的方案会更加多,这就留给大家自己思考吧!

为了获得更多的回报,为了成为世界的强者,这需要不断地奋斗,希望大家在新的一年里继续努力,获得更大的回报!

 

 

 

 

 

这篇关于从《天行九歌》到海盗问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/871476

相关文章

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操

Redis出现中文乱码的问题及解决

《Redis出现中文乱码的问题及解决》:本文主要介绍Redis出现中文乱码的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 问题的产生2China编程. 问题的解决redihttp://www.chinasem.cns数据进制问题的解决中文乱码问题解决总结

全面解析MySQL索引长度限制问题与解决方案

《全面解析MySQL索引长度限制问题与解决方案》MySQL对索引长度设限是为了保持高效的数据检索性能,这个限制不是MySQL的缺陷,而是数据库设计中的权衡结果,下面我们就来看看如何解决这一问题吧... 目录引言:为什么会有索引键长度问题?一、问题根源深度解析mysql索引长度限制原理实际场景示例二、五大解决

Springboot如何正确使用AOP问题

《Springboot如何正确使用AOP问题》:本文主要介绍Springboot如何正确使用AOP问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录​一、AOP概念二、切点表达式​execution表达式案例三、AOP通知四、springboot中使用AOP导出

Python中Tensorflow无法调用GPU问题的解决方法

《Python中Tensorflow无法调用GPU问题的解决方法》文章详解如何解决TensorFlow在Windows无法识别GPU的问题,需降级至2.10版本,安装匹配CUDA11.2和cuDNN... 当用以下代码查看GPU数量时,gpuspython返回的是一个空列表,说明tensorflow没有找到

解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题

《解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题》:本文主要介绍解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4... 目录未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘打开pom.XM

IDEA Maven提示:未解析的依赖项的问题及解决

《IDEAMaven提示:未解析的依赖项的问题及解决》:本文主要介绍IDEAMaven提示:未解析的依赖项的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录IDEA Maven提示:未解析的依编程赖项例如总结IDEA Maven提示:未解析的依赖项例如

Redis分片集群、数据读写规则问题小结

《Redis分片集群、数据读写规则问题小结》本文介绍了Redis分片集群的原理,通过数据分片和哈希槽机制解决单机内存限制与写瓶颈问题,实现分布式存储和高并发处理,但存在通信开销大、维护复杂及对事务支持... 目录一、分片集群解android决的问题二、分片集群图解 分片集群特征如何解决的上述问题?(与哨兵模

SpringBoot+Redis防止接口重复提交问题

《SpringBoot+Redis防止接口重复提交问题》:本文主要介绍SpringBoot+Redis防止接口重复提交问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不... 目录前言实现思路代码示例测试总结前言在项目的使用使用过程中,经常会出现某些操作在短时间内频繁提交。例