Weighted Prwin

From Maxin Wiki

A weighted prwin is one which is calculated by making informed selections of the cards opponents are likely to hold, and using these in the calculation of your win probability. Factors which can be used to make inferences about cards include willingness to pay to see flop, betting behaviour when faced by common cards, and historical information about opponent behaviour. Essentially it aims to put your opponents on cards as accurately as possible.

[edit] Openholdem Prwin

This has been implemented as of build 1.6.0. It is based on a fairly simple model using pre-flop behaviour. For dll coders OH 1.9.0 and above also allow the use of Enhanced Prwin.

User-defined functions in a .whx file return the following values, expressed as handrank169 values (see OpenHoldem:EndUserDocumentation:Symbols)

f$mustplay - opponents holding cards better than this are assumed always to play them. This allows for the situation where opponents slowplay the strongest hands in the hope of milking more from the pot with them.

f$topclip - indicates that hands better than this are less likely to be played, since the betting level is too low.

f$willplay - hands better than this will be played.

f$wontplay - hands worse than this are highly unlikely to be played.

The success in using a model of this sort depends on the data available to allow the formula coder to devise appropriate expressions for the f$functions outlined above. Currently in OH the most accessible is floppct - the percentage of opponents seeing the flop averaged over a user definable period. This is a reasonably accurate expression of the strength of cards which opponents are prepared to play. An example of its use could be:

f$willplay handsplayed<10?72:(180*floppct)>(nopponents*2+1)?180*floppct:nopponents*2+1

f$wontplay f$willplay*1.4

Note: As identified in the forum thread [1] OH up to and including 1.9.5 has code to protect the iterator from a value of f$willplay which is too low to allow hands to be assigned to each opponent, but omits the matching code for f$wontplay, which could cause the iterator to lock up. The protection factor in OH is also too low for some theoretically possible situations to be resolved in a reasonable time. The sample formula above protects against these. If f$willplay evaluates to zero prwin weighting will be turned off. f$wontplay should not be less f$willplay

Although this is primitive it gives the single greatest advantage of using a weighted prwin rather than an unweighted one; it eliminates the cards which opponents are unlikely to invest any money in from the calculation. Since it depends on statistical information a constant value is given until floppct has had time to establish itself. The '180' is because 90 is the midpoint of handrank169 at which the number of hands above and below are the same (the stronger hands tend to have fewer possible examples).

Ideally the calculation should be based on betting averages at different levels, since it is what opponents are prepared to pay that determines the probable strength of their hand, and should be recorded on an opponent (and even position) basis. The problem with more refined data accumulation is that it takes an increasing number of hands to gain significance, and is sensitive to changes in playing conditions, such as the number of players, which can alter opponent behaviour. Nevertheless statistics of this sort have been used successfully in other bots based on a weighted prwin, and may be available from OH in the future.

The OH weighted prwin uses a handrank169 table which is based on published data about hands players actually take to flop, and varies from conventional ones giving win probabilities, particularly in the way it favours suited hands! In the absence of statistical support it is not recommended that you implement f$topclip or f$mustplay unless you have a good picture of the standard of play at a table.

If f$willplay is absent, or returns a zero value, the prwin weighting is turned off. It will also be turned off if your f$P specifies more than 13 opponents. If your opponents at flop include a BB who has not been raised, no weighting will be applied to his hand, since no assumptions can be made about it.

You may need to change your f$P if using weighted prwin. P factor is a kludge to compensate for the fact that opponents who fold have weaker hands. Prwin weighting allows for this, and therefore a prwin bot is best coded by calculating using the actual number of opponents playing. A suggestion for an f$P, if you use prwin pre-flop, could be:

(nopponentsplaying==0) ? 0 : //zero if no opponents
 (br>1)? nopponentsplaying : //just use actual opponents post-flop
  (handsplayed<10)? nopponentsplaying : //fallback until floppct becomes reliable
   (nopponentscalling+nopponentsraising+nopponentschecking*floppct+0.49)<1 ? 1 : //this should never happen, but .....
    nopponentscalling+nopponentsraising+nopponentschecking*floppct+0.49 //make an estimate for opponents who have still to act

This attempts to estimate the number of opponents you are likely to face when you act pre-flop, and is most significant when you are in early position. Whilst the principle works that actual formulation has not been tested!

As of build 1.8.3 OH also offers dll coders Enhanced Prwin

[edit] Dynamic Use

Although really intended to provide weighting based on pre-flop behaviour, changes in the return values of the 'f$' functions which control prwin weighting will be applied the next time prwin is calculated by OH. If working from formula alone the re-calculation will occur when there is a change in the game state, so any changes you make may not be reflected immediately in the value of prwin unless you can trick OH into making a fresh calculation.