(flg_f_saw is needed to include forced all-in players).
Just "Played" mark could be placed to "PF" column...
Quote:
Originally Posted by plexiq
As a (very basic) improvement, you think it would help with the back-and-forth switching if you had an additional view with the hand history? ie: Option to view history & strategies at the same time - located like outline, quickgraph & co
Yeah, it will also help and gain the following benefit:
- walking thru hands in query we will instantly see not only outline of the hand, and now its history. It will help to navigate quickly.
Personally I will have this window either detached or tab-combined with quickgraph.
About zero effstack:
HM1 support reported that this problem already fixed in internal build dated Jul,9, I have checked it. This version imports hands correctly.
Interesting, there are remaining hands with zero eff.stack - when hero is forced all-in.
It means calculator correction was useful anyway - before we had no chance to analyze those hands.
So I got sequence ICM 47.5% -> PSM1 26% -> PSM2 93.6% -> PSM3 87.5% -> PSM4 49.3%.
Doesn't seem to be true…
I understood my confusion with those PSM results - BU range strongly depends on "BB call SB" range. And started to use PSM more widely than before.
Because of calculation time is increased in PSM - I realized: caching of NE strategy tables (lets define it NEST) is desired.
No matter of chip model, PSM or ICM. Even unrestricted ICM will take too much time for 10 tourney analysis.
Unfortunately, our computers have geekbench below 83k yet
But fortunately, caching ICM/PSM NEST will take low space and save lots of time. At least, additional HDD costs less than CPU/MB upgrade (joke, but also fact). Anyway, players' local disk space virtually unrestricted in term of Nash DB, but CPU speed is limited physically.
Users perform calculation of many different configurations, however, some of them are equal to previous, especially initial two-three hands of identical tourneys.
No need to calc NEST again and again for the same situations - it could be just cached.
On user's bulk-request for selected hands, cache could be queried and marks placed for:
- analysis has/hasn't been performed with any of chip models.
- if yes, - do holecards belong to range?
For non-marked hands, user is able to bulk-calculate and store results in cache.
Developing server-side cache will be enough to create good community-driven VI-FP DB ( and store Vi along with NESTi ).
Regarding cache, we have basically the same problem as with the VI-FP db you suggested: We need to find an extremely good match for the current stack vector for it to be any useful. Since (at least for the expensive hands) the dimensionality is quite big, this is not very practical.
And for this to make any sense we would need a quite good rate. Going through the trouble of all the additional space & implementing for 10% hits is simply not efficient. (There are other spots to get a 10% runtime decrease.)
Still busy with the licensing atm, but close to done. (Need to prepare some server side changes for this as well,...)
I will take a look at the SQL actions next, and if i can get at least some rough sequence out of all databases i think i will add a simple batch calculate mode right away. (Treating all hands as push/fold and doing a quick linear nash calculation to see if hero "made a mistake". Later we can follow up with a more expensive calculation for the close/interesting cases.)
Going through the trouble of all the additional space & implementing for 10% hits is simply not efficient. (There are other spots to get a 10% runtime decrease.)
I can carefully estimate it on my DB, if I could get some logs.
It should be easy for you - could you please provide me an option in calculator.ini to write on System.out some info of every hand that appear in query result?
Format of output line:
hand#, tourney#, position of the hand within a tourney(if possible)(most recent has max.position), plr count, bb, sb, ante, BB stack amount, SB stack amount, BU stack amount, so on.
I can carefully estimate it on my DB, if I could get some logs.
It should be easy for you - could you please provide me an option in calculator.ini to write on System.out some info of every hand that appear in query result?
Format of output line:
hand#, tourney#, position of the hand within a tourney(if possible)(most recent has max.position), plr count, bb, sb, ante, BB stack amount, SB stack amount, BU stack amount, so on.
Do you know some basic scripting / programming?
Guess it would be easier if i simply provide you with the queries i use. Actually, you can simply enable Postgresql query logging and see the queries in the logs - including all the parameters/filters you used in the program.
(Remember i don't have the stack positions in memory when displaying the tourney list, these are loaded when you click on a hand.)
To change stack sizes i basically need to create a completely new hand. (I guess i could add a convenient way to copy all ranges/settings over to a newly created hand though.)
Anyway, this would require quite a few changes. I will keep it in mind as a possible improvement after the release.
Thanx, I've used SQL queries from server log, and counted possible cache profit for my structure with basic SQL statements.
Spoiler:
create table NCcache_20120101 as (
select phh.pokerhand_id,
concat(phkc.gametype_id, ' ',phkc.numberofplayers, ' ',bigblind, '/' , smallblind, '/',ante
,': ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=0 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=1 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=2 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=3 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=4 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=5 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=6 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=7 limit 1)
,' ',(Select phtm.stacksize from playerhandstourneymisc phtm, playerhandstourneykeycolumns phtkc where phtm.playerhand_id=phtkc.playerhand_id and phtkc.pokerhand_id=phh.pokerhand_id and offthebutton=8 limit 1)
) as config
from tourneydata td, playerhandstourneykeycolumns_hero phkc, playerhandstourneymisc_hero phtm, gametypes gt, pokerhands_hero phh
where tourneysize<=9
and td.tourneynumber=phkc.tourneynumber and td.site_id=phh.site_id and gt.pokergametype=0 and gt.pokergame=1 and phh.pokerhand_id=phkc.pokerhand_id
and phkc.playerhand_id=phtm.playerhand_id and phkc.gametype_id=gt.gametype_id and date(phh.handtimestamp)>='2012-01-01'
)
Just did a quick checkup of the cache hits, seems most of them are either in the first few hands, or heads up / 3m where the whole orbit is folded etc.
Code:
select count(*), config from NCcache_20120101 group by config having count(*)>1 order by count(*) desc;
If i filter for hands with >3 players and exclude the obvious cache hits in the first 2 hands of the tourney, i am left with:
51.2k vs 49.5k
Can you please try exluding hands with <4 players and the top ~10-20 most common stack setups (which were all either starting stacks or starting stacks after sb/bb takes down blinds first hand)?
2-3 Handed can be calculated very quickly, they are not really worth caching since they don't contribute much to the total runtime anyway.
(Also, as discussed earlier itt, rounding by sb is not accurate enough.)
4plrs or more:
73041; 45257; 1.61391607928055
top hand repeated 7695 times, hands 2-30 repeated 108-899 times acc. others are way less.
excluding top 30 hands,
Code:
select sum(repeatcount) from (select * from NCcachecount offset 30) as cnt
56339; 45227; 1.24569394
Excluding top 20 hands (>=152 repeats)
57677; 45237; 1.27499613
Excluding top 10 top hands (>=285 repeats)
59663; 45247; 1.31860676
Unfortunately, still not extremely important speedup Early in the morning I expected more....
Yeh, the real speedup would be even smaller since the "expensive" hands with more players should be less likely to hit the cache, and the cache itself will cause a significant overhead.
Two Plus Two
Linear Mode
