文章 140
评论 163
浏览 322607
现代扑克理论02-博奕论基础-4

现代扑克理论02-博奕论基础-4

最小程度剥削策略(MinES) 我们再回到通灵玩具游戏解决方案。 底池大小:100美元 筹码量:100美元 公共牌面:3♠ 3♥ 3♣ 2♦ 2♠ 牌手1:EV 75美元 AA:下注100美元(100%),Check(0%) QQ:下注100美元(50%),Check(50%) 牌手2:EV 25美元 对抗Check:用KK 100% check 对抗100美元下注:50%的时候用KK跟注,50%的时候弃牌 假设有这个游戏的一个变体,Hero是牌手1,牌手2是一个倾向于做较松跟注的对手。他不是50%的时候用KK跟注,而是55%的时候跟注。 如果Hero继续采用GTO策略,他对抗这个漏洞赚不到任何额外EV。 AA的EV: AA下注的EV = 牌手2弃牌的EV * 牌手2弃牌率 +牌手2跟注的EV * 牌手2跟注率 AA下注的EV = 100 * 0.45 + 200 * 0.55 AA下注的EV = 45 + 110 AA下注的EV = 155美元 AA的EV = AA下注的EV * AA的下注率 + AA check的EV * AA的check率 AA的EV = 155 * 100% ....

游戏后门听牌的五个技巧

游戏后门听牌的五个技巧

后门听牌在范围构建过程中起着非常重要的作用。 如果你在牌桌上制定决策时没有经常考虑后门听牌,这篇文章就是为你而写的。 后门听牌并非只因为它们击中一手强牌的额外胜率而重要。后门听牌也因为你平均而言更频繁打到河牌圈,给你更多可玩性和允许你实现更多底池权益而宝贵。   1.当你的非成手牌具有后门同花听牌时,你应该更倾向于下注。 如果你有一副具有后门同花听牌的非对子底牌,你应该积极考虑下注(如果你有下注主动权)。尤其是你具有位置优势的时候。 用这些后门同花听牌下注是有利可图的,因为你可以在两种情况下在转牌圈用它们诈唬: l当转牌给你一副同花听牌时。你获得了很多胜率,因此你通常应该用二次下注(double barrel)延续你的侵略性。此外,你也可能在河牌圈改进成一副同花,赢得一个可观的底池。 l当许多听牌完成时。在完成直接听牌的超恐怖牌面下注可能使对手过度弃牌(over-fold)。这些对手往往认为“所有半诈唬牌都已经完成,因此他不太可能在诈唬。” 后门同花听牌可以使一手值得弃牌的牌变成一手值得跟注的牌。 假设你在按钮位置用86率先加注,然后在T♠ 7♠ 3♦翻牌面下注,和大盲玩....

GFW的闭环

GFW的闭环

今天看到一篇文章,很有意思。转载到自己的博客上。 以下为转载内容。 每当我看到无时无日不开着 VPN 的人说某篇文章或某个话题被「全网删除」的时候,都觉得 GFW 已经,呃,闭环了。 几乎没有一次指的是全网删除,从来都是「从中国的互联网上删除」。随着这个语言习惯的普及,简体中文世界的人越来越把全网等同于全中国的网。

梦想与现实

梦想与现实

每个人在步入社会的时候,都怀揣着远大的理想。并且都会为了这个理想不断的拼搏努力,但是当被现实的社会蹂躏的体无完肤的时候,你还相信梦想么? 从前的我从来不相信命运,一直都相信人定胜天,但是随着岁月的流逝。仿佛当年那个意气风发的少年已经不复存在了,而目前的我早已没有了远大的抱负,已经开始像这个现实的社会认输了。第二次创业的艰辛让我已经失去了人生的方向,更别说目标了。我们每个人都一直在找寻生命的意义,但是在这几年的经历切切实实的告诉我,不要想着凤凰涅槃。你只不过是个凡人,不要高估自己的造化。如行尸走肉般的活着就不错了。 30年的人生岁月经历了破产,众叛亲离,生死离别,我的人生集合了五味杂陈,再也没有了梦想,没有了激情。也许这是最后一次创业,也算是给自己一个交代。成功与失败都必须欣然接受。是的,你必须要承认梦想与现实差距永远是巨大的。你不在年轻,你也不再优秀。 既然没有勇气死,就活着吧。勤勤恳恳的完成这一次创业,给自己人生画上一个句号。也许这就是生命的意义吧,就像拉康说的,幻想必须超越现实,因为在你到手的那一刹那,你没办法也不会再想要它。

Ubuntu 16.04 升级到 18.04 LTS 笔记

Ubuntu 16.04 升级到 18.04 LTS 笔记

更新Ubuntu 16.04 在升级之前,先更新当前的16.04至最新状态。建议升级之前更新/升级所有已安装的软件包。 首先更新APT源和软件包至最新 sudo apt update && sudo apt dist-upgrade && sudo apt autoremove 安装和配置Ubuntu update manager 更新完组件后,运行以下命令安装update-manager-core sudo apt install update-manager-core 打开update-manager配置文件 sudo nano /etc/update-manager/release-upgrades 确保设置为Prompt=lts 执行升级命令 sudo do-release-upgrade -d 出现升级提示时,全部选择y 等待所有的软件包下载...安装...到重启... 当所有操作执行完毕后,系统就升级到最新的Ubuntu 18.04 LTS版本了。

typecho博客域名设置

typecho博客域名设置

这两天弄了一个tyecho博客,在配置的过程中发现用WWW访问的时候首页有许多图标没有显示,于是看过主题代码发现原来是网站的图标调用的是绑定域名的绝对路径,所以导致用其他域名或显示不正常。 没办法,只能采用301跳转了。可以直接在宝塔的重定向设置 或是更改Nginx配置: 1. if ($host ~ '^www.tian0616.com') 2. {return 301 https://tian0616.com$uri;} 最后更改下域名解析A记录到指定IP,这样所有域名就全部会跳转到指定的二级域名了。 感慨这些方面SOLO做的真的比其他的博客要好。

改革前行,保守则退

改革前行,保守则退

最近在看关于宋朝的一本书汴京之围,该书通过通俗的语言大致像读者讲述了宋朝的兴衰史。从这本书中让我有了一些对改革和保守这两个反义词的新解读。 其实中国有句古话,逆水行舟,不进则退。这句话已经很鲜明的告诉了世人,一个社会如果要发展,如果要向前,就必须时时刻刻都需要改革,只不过在具体实施改革的方式上需要考量。是激进的打破一切默守陈规,还是温和的逐步优化,这就是学问所在了。 纵观中国历史,凡是激进的改革基本均已失败而告终,为什么呢?这里先说说什么是保守派,在中国所谓的保守派就是既得利益者,享受着体制带来的优越性。这部分人绝非少数,用28定律来解释最好,这部分人掌握着社会的大部分资源和财富。换做是你,你希望改革么?答案是显而易见的,因为一旦改革必将触动这部分人的利益,所以说没有什么纯粹的保守派,只不过是利益的拥护者。所以激进的改革派为什么都以失败而告终就显而易见了。 但是矛盾点在于不改革社会就会僵化,导致贪腐滋生,就有亡朝的风险。但是激进的改革阻力又过大,无法实施,这个周期越长,王朝就越衰败。最后导致起义,变革。建立新的朝代,然后在起义、变革建立新的朝代,周而复始的循环下去。好像这确实就是我们的....

马云卸任演讲

马云卸任演讲

每一本关于马云的书我基本都阅览过,给我最大的启迪就是人要有梦想,人更要有格局。通过沉淀自己,用最大的胸怀去完成最有意义的梦想。这就是事业成功的真谛。一切杂念刨除,为了自己的梦想前进,若干年回头看,你会发现,你已经是个富有的人了。 这不是一个时代的结束,就像马云说的,这是一个制度的传承。 青山不改,绿水长流,再见马云。

宝塔面板 – Java 项目管理器安装Solo博客教程

宝塔面板 – Java 项目管理器安装Solo博客教程

最新通过宝塔部署了SOLO,在实际体验过程中发现该BLOG还是很好用的,除了必须绑定GITHUB这点上比较反人类(也可能是开发者的大构思,只是我们没有深刻去理解)其他方面都是很好的,重点是用不断更。所以现在使用起来也是非常不错的,在这里记录下自己的搭建过程和修改内容。并提出更新疑问。 1.安装宝塔里面的JAVA管理器,然后选择安装Tomcat9 2.找到tomcat的webapps的位置,直接下载进去,会自动给我们解压的 下载地址:https://github.com/b3log/solo/releases/ 3.添加项目,域名提前解析好即可。 4.添加数据库 用户名Solo,格式utf8m64 5.配置local.properties 路径 /www/server/tomcat9/webapps/solo-v3.6.4/WEB-INF/classes 改成创建的数据库名称,和数据库密码。 6.在JAVA管理器中映射该项目 7.修改latke.properties 路径 /www/server/tomcat9/webapps/solo-v3.6.4/WEB-INF/classe....

Ssmgr面板不统计流量原因排查

Ssmgr面板不统计流量原因排查

今天升级了自己的三台世界加速服务器,但是发现面板不统计流量,也不显示用户在线情况。但是连接,建账号一切都是正常的。于是开始了我的排查之旅。 1.第一反应是不是数据库损坏,导致无法写入,下载数据库后发现一切正常。排除 2.是不是某个节点因为升级过程中有覆盖,于是重新查看了相应的配置文件,发现正常。排除 3.肯定是主服务器问题,而且又排除了数据库问题,设置也都没有问题,那么我首先想到的就是Redis了。 redis-cli //登陆 flushall //清除缓存 redis-cli -h 127.0.0.1 -p 6379 shutdown //关闭redis redis-server //启动redis 清除库缓存并重启后发现一切正常。果然是缓存惹的祸。不过在不确定缓存是否重要的时候,不建议使用盲目的删除,以免重要数据丢失。