bupticybee / TexasSolver

🚀 A very efficient Texas Holdem GTO solver :spades::hearts::clubs::diamonds:
https://bupticybee.github.io/texassolver_page
GNU Affero General Public License v3.0
1.65k stars 294 forks source link

关于console_solver的使用问题:运行速度以及输出格式 #102

Closed jason768719 closed 2 years ago

jason768719 commented 2 years ago

您好,我近期才看到您的软件,它真的非常棒,我正在试用中,目前使用一切正常,但我在使用console_solver的过程中发现以下问题: 一、console_solver的启动速度可以优化吗? 我原本以为console_solver的运行速度会更快,但使用中发现软件在提示[##################################################] 100%这个信息的过程每次都需要花费大约8秒的时间,我不知道是不是软件的启动时间,但在GUI中,只要打开软件后,每次我计算转牌或河牌只需要1-2秒的时间,如果我用console_solver计算转牌或河牌,加上前面的启动时间,每次就会需要10秒左右,这个不知道是不是软件启动时间,可以优化一下吗? 二、关于系统输出结果的格式 在目前输出的结果中,有很多的重复信息,打开后会显得零乱。我仍然在有点困难的阅读、理解和熟悉的过程中。这个软件输出结果作为软件最重要最核心的功能,其格式能否在下个版本中有优化。不过,我个人非常不建议您在其他帖子的答复的,您要开发自己独创的格式,这会产生兼容的问题,我自己在使用中也是通过console_solver中设置其输出为txt格式文本并使用的,虽然我同时也在用firefox读取结果,txt格式会最大化的解决您的软件与其他软件使用中的兼容问题。这个仅供参考。 最后,瑕不掩玉,正是因为您的软件非常好,所以提以上这些问题,希望它更好,更完善。非常希望在您方便的时候得到您的回复,期待它的下一个版本,谢谢!加油!!

bupticybee commented 2 years ago

是可以极大加速的,最近有一个pr解决了这个问题: https://github.com/bupticybee/TexasSolver/pull/94 可以将加载速度缩短到1s以内,不过我还没有将这个特性merge到console版本中,如果你感兴趣的话可以一起帮忙下?

jason768719 commented 2 years ago

那真的太棒了,请问他是用什么方法做到的,我可以帮忙做些什么呢?

bupticybee commented 2 years ago

那真的太棒了,请问他是用什么方法做到的,我可以帮忙做些什么呢?

大幅简化了compairer表格,缩小到了原来的1/20不到,加载速度也相应提升了至少20多倍,你要是会c++的话可以帮忙把相应变动迁移到console分支,这块我最近在摸鱼所以一直没做(逃

bupticybee commented 2 years ago

另外其他的格式肯定会是尽可能是可读的格式,来符合开源项目的定位(也就是你说的txt之类的),但是具体能不能说做到用文本编辑器打开就能阅读,这个我没法保证

jason768719 commented 2 years ago

真的很遗憾,我还不会C++,我会找些课程来学习一下,希望以后我能帮上忙。

bupticybee commented 2 years ago

好的

jason768719 commented 2 years ago

你好,从上次你的答复得知console_solver的加载速度可以优化,对我而言,如果能优化加载速度,这个软件已经接近完美。所以想再请问一下,关于console_solver加载功能的优化大约什么时候能够完成?只要有优化这个功能的2.1版本就可以,我看了之前你引用的记录,大致理解了是怎么回事,但不知如何修改,如果有需要,我可以提供力所能及的帮助,例如承担完成这项工作费用或者协助完成其中部分工作,另外,我也专门为此报了C++课程,但还在学习中,所以,很希望关于这项功能的优化情况得到您的回复,看看我能在实际上帮上什么忙?另外,我在使用了json解析之后,json格式读取数据还是相当方便的,我慢慢习惯了这个格式。您可以这里回复或通过邮件14093141@qq.com或电话以及微信15088669188和我联系,谢谢你。

bupticybee commented 2 years ago

你好,从上次你的答复得知console_solver的加载速度可以优化,对我而言,如果能优化加载速度,这个软件已经接近完美。所以想再请问一下,关于console_solver加载功能的优化大约什么时候能够完成?只要有优化这个功能的2.1版本就可以,我看了之前你引用的记录,大致理解了是怎么回事,但不知如何修改,如果有需要,我可以提供力所能及的帮助,例如承担完成这项工作费用或者协助完成其中部分工作,另外,我也专门为此报了C++课程,但还在学习中,所以,很希望关于这项功能的优化情况得到您的回复,看看我能在实际上帮上什么忙?另外,我在使用了json解析之后,json格式读取数据还是相当方便的,我慢慢习惯了这个格式。您可以这里回复或通过邮件14093141@qq.com或电话以及微信15088669188和我联系,谢谢你。

wow,那还挺有益处的,如果这个项目能够通过这种方式帮到你我感到很开心,优化情况的话现在我有几项TODO,不过一直在摸鱼没做:

  1. json不是一个很好的德州策略格式,效率太低,保存太慢,这里本来计划大改
  2. 策略现在只能保存,没法读取,这里也是一个重要TODO
  3. 计划开发基于求解结果的trainer
  4. node locking等常规solver功能
  5. 速度优化,现在版本还是比piosolver慢

你可以挑选你自己感兴趣的方形,我们一起做

bupticybee commented 2 years ago

至于下个版本,我认为上面列举的功能至少完成1~2个才会考虑发布新版本吧,不然两个版本间功能差距太小了

jason768719 commented 2 years ago

你好,我作为扑克玩家,在您的后期计划中,我对node locking特别感兴趣,我理解它可以针对对手进行偏移,采用剥削型打法,非常希望您能够将它作为优先选项,来实现例如最常见的针对跟注站,减少诈唬的频率,对于几乎从不加注的玩家,增加薄价值下注的频率,对于转牌很少下注的玩家,增加跟注的频率。我想这才是用SOLVER最终要实现的功能,确定基准后再根据对手进行偏移,实现这点才是扑克玩家终极的目标。想到这点很让人兴奋,因为这种状态会将目前实现的功能提升到另一个完全不同的层级,这会是质的飞跃,我非常期待后期能有这项功能。但让我先回到现实,我目前用您的软件和其他几款软件搭建了一个系统,实现了在实时牌局中,获取对手的范围并根据牌局的进程读取SOLVER的结果,确定标准的打法,以此对照改进自己的打法,如果我愿意甚至也可以让它全自动的完成一个牌局,当然目前SOLVER只能从转牌开始介入,可能我用自己的方法实现了你想要的trainer的功能。所以,console_solver的加载速度是目前最大的瓶颈,实时牌局中给玩家的思考时间基本都在15秒以内,它浪费了太多实时牌局中宝贵的时间,相比这下json的存取速度还可以接受,所以我想再澄清一下,我非常希望能尽快先完成console_solver加载速度的优化,这在实时牌局的使用中实在让人无法忍受。这项优化会将加载速度从目前的速度提高到258分之一,这是一个性能的飞跃,不知道为什么您对此无动于衷。我太期待这项加载速度的优化了,所以我为此还报了C++的课程,希望自己会有能力来解决系统中这最后一个瓶颈,但目前确实还不知如何下手,所以只能再次请求您先把这项工作完成吧,不要让用户再忍受这个加载时间太久了,这对我真的会是一个解放,再次感谢您!

bupticybee commented 2 years ago

你好,我作为扑克玩家,在您的后期计划中,我对node locking特别感兴趣,我理解它可以针对对手进行偏移,采用剥削型打法,非常希望您能够将它作为优先选项,来实现例如最常见的针对跟注站,减少诈唬的频率,对于几乎从不加注的玩家,增加薄价值下注的频率,对于转牌很少下注的玩家,增加跟注的频率。我想这才是用SOLVER最终要实现的功能,确定基准后再根据对手进行偏移,实现这点才是扑克玩家终极的目标。想到这点很让人兴奋,因为这种状态会将目前实现的功能提升到另一个完全不同的层级,这会是质的飞跃,我非常期待后期能有这项功能。但让我先回到现实,我目前用您的软件和其他几款软件搭建了一个系统,实现了在实时牌局中,获取对手的范围并根据牌局的进程读取SOLVER的结果,确定标准的打法,以此对照改进自己的打法,如果我愿意甚至也可以让它全自动的完成一个牌局,当然目前SOLVER只能从转牌开始介入,可能我用自己的方法实现了你想要的trainer的功能。所以,console_solver的加载速度是目前最大的瓶颈,实时牌局中给玩家的思考时间基本都在15秒以内,它浪费了太多实时牌局中宝贵的时间,相比这下json的存取速度还可以接受,所以我想再澄清一下,我非常希望能尽快先完成console_solver加载速度的优化,这在实时牌局的使用中实在让人无法忍受。这项优化会将加载速度从目前的速度提高到258分之一,这是一个性能的飞跃,不知道为什么您对此无动于衷。我太期待这项加载速度的优化了,所以我为此还报了C++的课程,希望自己会有能力来解决系统中这最后一个瓶颈,但目前确实还不知如何下手,所以只能再次请求您先把这项工作完成吧,不要让用户再忍受这个加载时间太久了,这对我真的会是一个解放,再次感谢您!

嗯嗯,这项工作其实比较简单,我找个时间做一下

bupticybee commented 2 years ago

你好,我作为扑克玩家,在您的后期计划中,我对node locking特别感兴趣,我理解它可以针对对手进行偏移,采用剥削型打法,非常希望您能够将它作为优先选项,来实现例如最常见的针对跟注站,减少诈唬的频率,对于几乎从不加注的玩家,增加薄价值下注的频率,对于转牌很少下注的玩家,增加跟注的频率。我想这才是用SOLVER最终要实现的功能,确定基准后再根据对手进行偏移,实现这点才是扑克玩家终极的目标。想到这点很让人兴奋,因为这种状态会将目前实现的功能提升到另一个完全不同的层级,这会是质的飞跃,我非常期待后期能有这项功能。但让我先回到现实,我目前用您的软件和其他几款软件搭建了一个系统,实现了在实时牌局中,获取对手的范围并根据牌局的进程读取SOLVER的结果,确定标准的打法,以此对照改进自己的打法,如果我愿意甚至也可以让它全自动的完成一个牌局,当然目前SOLVER只能从转牌开始介入,可能我用自己的方法实现了你想要的trainer的功能。所以,console_solver的加载速度是目前最大的瓶颈,实时牌局中给玩家的思考时间基本都在15秒以内,它浪费了太多实时牌局中宝贵的时间,相比这下json的存取速度还可以接受,所以我想再澄清一下,我非常希望能尽快先完成console_solver加载速度的优化,这在实时牌局的使用中实在让人无法忍受。这项优化会将加载速度从目前的速度提高到258分之一,这是一个性能的飞跃,不知道为什么您对此无动于衷。我太期待这项加载速度的优化了,所以我为此还报了C++的课程,希望自己会有能力来解决系统中这最后一个瓶颈,但目前确实还不知如何下手,所以只能再次请求您先把这项工作完成吧,不要让用户再忍受这个加载时间太久了,这对我真的会是一个解放,再次感谢您!

这个问题我一直没解决其实是因为console solver其实一直是支持预加载功能的,可以提前加载资源,solving的时候只需要输入参数,甚至支持提前建树,solving的时候只需要输入range,所以在我看已经有一种解决方案的时候另一种就没那么紧迫了

jason768719 commented 2 years ago

那实在太棒了,感谢您的宝贵时间,日夜期盼之中……

jason768719 commented 2 years ago

因为目前console_solver加载速度慢的问题仍未解决呢,所以重开一下本问题,恳请icybee能尽快帮忙解决,万分感谢!因为我计划实战测试1万手和10万手后将solver实战的结果给大家分享一下,看看solver的成绩实战是否能够盈利以及盈利的水平。10万手牌每手节约大约8秒,这可是涉及80万秒的待解决问题,另外可以减少现在频繁的因为超时弃牌的出错。恳请icybee百忙中能抽空尽快完成,从目前几千手的结果看,并不太乐观,目前的solver实战结果是持平,这也是我想要通过大样本确认的,GTO的打法最终结果是否是仅能确保不被剥削,那是否意识着仅仅结果只是不输吗?实际结果比任何理论和推论都有说服力。谢谢!

bupticybee commented 2 years ago

ok,我计划一下排期

bupticybee commented 2 years ago

因为目前console_solver加载速度慢的问题仍未解决呢,所以重开一下本问题,恳请icybee能尽快帮忙解决,万分感谢!因为我计划实战测试1万手和10万手后将solver实战的结果给大家分享一下,看看solver的成绩实战是否能够盈利以及盈利的水平。10万手牌每手节约大约8秒,这可是涉及80万秒的待解决问题,另外可以减少现在频繁的因为超时弃牌的出错。恳请icybee百忙中能抽空尽快完成,从目前几千手的结果看,并不太乐观,目前的solver实战结果是持平,这也是我想要通过大样本确认的,GTO的打法最终结果是否是仅能确保不被剥削,那是否意识着仅仅结果只是不输吗?实际结果比任何理论和推论都有说服力。谢谢!

我不太建议拿solver直接去实战,flop是没法实时算的,你的计划里边怎么解决这一部分么?

jason768719 commented 2 years ago

按目前的计算速度,solver确实只能从转牌开始计算,我翻牌思路是通过equity结合底池大小计算EV来进行处理的,如果没有位置,默认过牌,如果翻牌的equity超过我设定的阈值且跟注是正ev,过牌跟注,如果有位置,equity超过阈值或者结合对手的弃牌率计算一下诈唬的EV,如果正EV就下注,否则弃牌。翻牌的这个处理和GTO的结果可能有细微的差异,但我认为可以接受,因为它的基本原则和GTO一样的,前位尽可能构建一个紧缩的范围去抓诈唬,后位尽可能构建一个两极化的范围。所以我测试的只是转牌开始solver实战的表现。

bupticybee commented 2 years ago

按目前的计算速度,solver确实只能从转牌开始计算,我翻牌思路是通过equity结合底池大小计算EV来进行处理的,如果没有位置,默认过牌,如果翻牌的equity超过我设定的阈值且跟注是正ev,过牌跟注,如果有位置,equity超过阈值或者结合对手的弃牌率计算一下诈唬的EV,如果正EV就下注,否则弃牌。翻牌的这个处理和GTO的结果可能有细微的差异,但我认为可以接受,因为它的基本原则和GTO一样的,前位尽可能构建一个紧缩的范围去抓诈唬,后位尽可能构建一个两极化的范围。所以我测试的只是转牌开始solver实战的表现。

啊这好吧这样你的范围肯定构建的都不准确呀,如果偏离GTO很远的话我只能说我也不会惊讶

yffbit commented 2 years ago

@jason768719

GTO的打法最终结果是否是仅能确保不被剥削,那是否意识着仅仅结果只是不输吗?

CFR算法得到的是纳什均衡近似解,纳什均衡的意义在于双方都不能通过单独改变策略而提高自己的期望收益。如果双方的策略组成纳什均衡,那么双方都没有改变自身策略的动机(或者同时改变策略从而组成另一个纳什均衡)。如果游戏是公平的,那么双方的期望收益均为0,否则不利的一方没必要参与游戏。

实际结果比任何理论和推论都有说服力。

一个算法如果没有理论证明,你能安心地用到实践中?

jason768719 commented 2 years ago

本问题已解决,特别感谢yffbit ! 感谢icybee!