Jakoo

My Heart is a Ghost Town


  • Home

  • Categories

  • Archives

  • Tags

  • About

几个博弈论的概念

Posted on 2019-02-11

囚徒困境

囚徒困境 (英语:Prisoner’s Dilemma) 是博弈论的非零和博弈中具代表性的例子,反映个人最佳选择并非团体最佳选择。或者说在一个群体中,个人做出理性选择却往往导致集体的非理性。虽然困境本身只属模型性质,但现实中的价格竞争、环境保护等方面,也会频繁出现类似情况。

单次发生的囚徒困境,和多次重复的囚徒困境结果不会一样。

在重复的囚徒困境中,博弈被反复地进行。因而每个参与者都有机会去“惩罚”另一个参与者前一回合的不合作行为。这时,合作可能会作为均衡的结果出现。欺骗的动机这时可能被受到惩罚的威胁所克服,从而可能导向一个较好的、合作的结果。作为反复接近无限的数量,纳什均衡趋向于帕累托最优。

囚徒困境的主旨为,囚徒们彼此合作,坚不吐实,可为全体带来最佳利益(缩短刑期),但在无法沟通的情况下,因为出卖同伙可为自己带来利益(无罪开释),也因为同伙把自己招出来可为他带来利益,因此彼此出卖虽违反最佳共同利益,反而是自己最大利益所在。但实际上,执法机构不可能设立如此情境来诱使所有囚徒招供,因为囚徒们必须考虑刑期以外之因素(出卖同伙会受到报复等),而无法完全以执法者所设立之利益(刑期)作考量,所以这是一个参考性的学术问题。

经典的囚徒困境
1950年,由就职于兰德公司的梅里尔·弗勒德和梅尔文·德雷希尔拟定出相关困境的理论,后来由顾问艾伯特·塔克以囚徒方式阐述,并命名为“囚徒困境”。经典的囚徒困境如下:
警方逮捕甲、乙两名嫌疑犯,但没有足够证据指控二人有罪。于是警方分开囚禁嫌疑犯,分别和二人见面,并向双方提供以下相同的选择:
若一人认罪并作证检控对方(相关术语称“背叛”对方),而对方保持沉默,此人将即时获释,沉默者将判监10年。
若二人都保持沉默(相关术语称互相“合作”),则二人同样判监半年。
若二人都互相检举(互相“背叛”),则二人同样判监5年。

用表格概述如下:

乙沉默(合作) 乙认罪(背叛)
甲沉默(合作) 二人同服刑半年 甲服刑10年;乙即时获释
甲认罪(背叛) 甲即时获释;乙服刑10年 二人同服刑5年
解说

如同博弈论的其他例证,囚徒困境假定每个参与者(即“囚徒”)都是利己的,即都寻求最大自身利益,而不关心另一参与者的利益。参与者某一策略所得利益,如果在任何情况下都比其他策略要低的话,此策略称为“严格劣势”,理性的参与者绝不会选择。另外,没有任何其他力量干预个人决策,参与者可完全按照自己意愿选择策略。

囚徒到底应该选择哪一项策略,才能将自己个人的刑期缩至最短?两名囚徒由于隔绝监禁,并不知道对方选择;而即使他们能交谈,还是未必能够尽信对方不会反口。就个人的理性选择而言,检举背叛对方所得刑期,总比沉默要来得低。试设想困境中两名理性囚徒会如何作出选择:

  • 若对方沉默、我背叛会让我获释,所以会选择背叛。
  • 若对方背叛指控我,我也要指控对方才能得到较低的刑期,所以也是会选择背叛。

二人面对的情况一样,所以二人的理性思考都会得出相同的结论——选择背叛。背叛是两种策略之中的支配性策略。因此,这场博弈中唯一可能达到的纳什均衡,就是双方参与者都背叛对方,结果二人同样服刑5年。

这场博弈的纳什均衡,显然不是顾及团体利益的帕累托最优解决方案。以全体利益而言,如果两个参与者都合作保持沉默,两人都只会被判刑半年,总体利益更高,结果也比两人背叛对方、判刑5年的情况较佳。但根据以上假设,二人均为理性的个人,且只追求自己个人利益。均衡状况会是两个囚徒都选择背叛,结果二人判监均比合作为高,总体利益较合作为低。这就是“困境”所在。例子有效地证明了:非零和博弈中,帕累托最优和纳什均衡是互相冲突的。

固定局数的囚徒困境

概括而言囚徒困境进行第一次后会出现以下两种情况:

  • 甲在第一次中被乙指控,即会在第二次指控乙,最终导致,甲即时获释,乙服刑10年或二人同服刑5年这两种情况。
  • 双方均保持沉默,即会建立互信的关系,最终导致,二人同服刑半年。

但互信的关系并非牢不可破,这一点也可以被利用,即甲,乙在第一次中共同选择沉默而赢得对方的信任,但甲或乙中的一人在获得对方的信任后指控对方而获得自身最大的利益即自身即时获释,但对方将服刑10年。这是一个以牺牲对方利益而获得自身最大利益的一种策略。

假设,两个囚徒均欲利用此策略,并将局数推演为十次,那么就会出现如下的情况:在第一局到第九局的过程中双方均会保持沉默,以期望建立互信关系,并在第十局指控对方,这将最终导致,二人同服刑5年。

再一次假设,双方都明确对方会使用与自己同样的策略,即知道对方会在第十局中指控自己,这样,在第九局时两者间的信任关系的建立即是没有意义的,如此类推,第八局到第一局中信任关系的建立也是没有意义的,即是十局都会互相背叛,也就是纳什均衡。也可推论,在如此的情况下,只有在囚徒困境的局数在不肯定的情况下(即双方均不知道进行的局数),才会出现互相保持沉默以获得信任关系的现象。

纳什均衡点

帕雷托最优

波兰表示法

Posted on 2018-12-25

概念

波兰表示法(Polish notation,或波兰记法),是一种逻辑、算术和代数表示方法,其特点是操作符置于操作数的前面,因此也称做前缀表示法。如果操作符的元数(arity)是固定的,则语法上不需要括号仍然能被无歧义地解析。波兰记法是波兰数学家扬·武卡谢维奇1920年代引入的,用于简化命题逻辑。

扬·武卡谢维奇本人提到:

我在1924年突然有了一个无需括号的表达方法,我在文章第一次使用了这种表示法.
—— Łukasiewicz(1), p. 610, footnote.

算术形式

表达“三加四”时,前缀记法写作“+ 3 4”,而不是“3 + 4”。在复杂的表达式中,操作符仍然在操作数的前面,但操作数可能是包含操作符的平凡表达式。例如,如下的前缀表达是:
*(− 5 6) 7

或省略括号:
* − 5 6 7

由于简单的算术运算符都是二元的,该前缀表达式无需括号,且表述是无歧义的。在前面的例子里,中缀形式的括号是必需的,如果将括号移动到:
5 − (6 * 7)

即:
5 − 6 * 7

则会改变整个表达式的值。而其正确的前缀形式是:
− 5 * 6 7
减法运算要等它的两个操作数(5;6和7的乘积)都完成时才会处理。在任何表示法中,最里面的表达式最先运算,而在波兰表达式中,决定“最里面”的是顺序而不是括号。

简单算术的前缀表达式主要是用于学术研究方面。与逆波兰表示法不同,前缀表达式基本没有在商业计算器中使用过,但是其体系经常在编译器构造的概念教学中首先使用。

计算机编程

Lisp的S-表达式中广泛地使用了前缀记法,S-表达式中使用了括号是因为它的算术操作符有可变的元数(arity)。逆波兰表示法在许多基于堆栈的程序语言(如PostScript)中使用,以及是一些计算器(特别是惠普)的运算原理。

假定只有二元运算时,操作数的个数必然为操作符的个数加一,否则表达式就无意义。这样在计算更复杂,更长的表达式时,可以简单地忽略某些错误表达式,因此在使用前缀记法时必须小心仔细检查其表达意义。

运算顺序

前缀表达式的运算顺序很容易检测。需注意的是,当运算时,操作符是作用在第一个操作数上,特别是需注意不满足交换律的运算,如除法、减法。例如,下列式子:

/ 10 5 = 2 (前缀记法)

表示10/5,结果是2,而不是½。

基于堆栈的操作符由于其本身的特性,无需括号也很容易区分运算的顺序,因此大量使用波兰记法。运算波兰表达式时,无需记住运算的层次,只需要直接寻找第一个运算的操作符。以二元运算为例,从左至右读入表达式,遇到一个操作符后跟随两个操作数时,则计算之,然后将结果作为操作数替换这个操作符和两个操作数;重复此步骤,直至所有操作符处理完毕。因为在正确的前缀表达式中,操作数必然比操作符多一个,所以必然能找到一个操作符符合运算条件;而替换时,两个操作数和一个操作符替换为一个操作数,所以减少了各一个操作符和操作数,仍然可以迭代运算直至计算整个式子。多元运算也类似,遇到足够的操作数即产生运算,迭代直至完成。迭代结束的条件由表达式的正确性来保证。

MySQL查询异常:找不到表名

Posted on 2017-02-23
MySQL查询异常:找不到表名

找不到数据库表名,但是数据库又实际存在表,报错如下,确定导致报错的原因,开始排查问题

以前的小东西,启起来是发现数据没有,以为是前端的问题,排查后发现,前端代码没有问题,然后开启Debug模式,发现数据没有正常从数据库拿到,报错如下:

HTTP Status 500 - Request processing failed; nested exception is org.springframework.jdbc.BadSqlGrammarException:

1
2
3
4
5
exception
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.jdbc.BadSqlGrammarException:
Error querying database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'ele_employeeInfo.ele_shikigami' doesn't exist
The error may exist in file [/Library/tomcat/webapps/ROOT/WEB-INF/classes/mappers/EleShikigamiMapper.xml]

bad SQL grammar []; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table ‘ele_employeeInfo.ele_shikigami’ doesn’t exist
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:979)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:858)
javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

错误一目了然,是找不到表。 原因:之前连接的数据库是本地的,现在连接的是服务器,Linux系统的数据库。本地连接貌似没有对查询语句的表名大小写有要求,远程到Linux就要区分了。数据库连的服务器的,本地当然找不到了😂 解决:把查询语句的表名大小写改成与数据库匹配的即可。😂

123
Jakoo

Jakoo

Denn man hat in der Welt nicht viel mehr, als die Wahl zwischen Einsamkeit und Gemeinheit.

8 posts
2 categories
2 tags
GitHub
© 2019 Jakoo
Powered by Hexo
Theme - NexT.Mist