Poker Hand XML

[TSchauenberg]

[ QUOTE ]

PokerHandXML 1.3.2 (Comments)
<!-- action types: fold, call, check, bet, raise -->
<!-- when you bet raise or call an amount is required -->
<!-- if betting obv specify the bet amount -->
<!-- if raising use the value that you raise TO (total amunt you have in pot so far) -->
<!-- if calling specify how much extra you put in to call (so on top of what you already have in) -->
<!-- allin="false" is optional and that is the default, but allin="true" is REQUIRED if this action -->
<!-- has put this player all-in -->


[/ QUOTE ]
We need to handle "completes" and the partial bets/raises that increase the amount of money people put in the pot but does not reopen the betting. Any ideas how to do this? I have never implemented this yet so am unsure how to proceed/recommend here.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
Likewise, should we not include who won the hand and who lost?

[/ QUOTE ]

To figure that out would require some type of hand rank chart code. Definitely not a good idea, it makes things overly complicated for everyone.

[/ QUOTE ]
Not including who won the hand is a very big mistake imho. It would not require any hand rank chart! The application creating these XML files is converting from the pokersite format - and those already include who wins and who looses, it'd be a simple matter of transferring that to an attribute. No calculation is done neither place.

[ QUOTE ]
[ QUOTE ]
and it'll save the importing application a lot of time if it's primarily interested in the net values

[/ QUOTE ]

How do you figure? You are severely underestimating the speed at which a CPU can calculate.

A developer's GetAmountWon() or GetPotSizeOnStreet(x) methods would be doing math like...

totalPot = a + b + c + d

Trust me, CPUs know how to count fast. The amount of time it takes to do this type of math on the fly is pure jokes.

[/ QUOTE ]
Now this is some funny stuff. You cannot compare iterating integers to parsing the XML file, taking care of all player actions, counting the pot together, deducting rake, jackpot amounts and so forth. The thing is that that requires some serious code to parse the XML and count the sum, there is absolutely no reason for the converting application not to do this along the way as is required anyways.

And if you think I'm talking about speed, you're dead wrong. I'm talking about code complexity.

[OrcaDK]

[ QUOTE ]
I don't see the harm in having an optional attribute for player reads. I don't think anybody is proposing making this mandatory. All rvg is saying is that he will want to add player reads/notes for some hnads and he would like to get agreement on the best way to do this. My understanding of xml is limited but if a parser is expecting :-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0"/>

it should not break if it gets:-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0" read = "85/40/0.1 DONKEY!"/>

The advantage of specifying at this point how reads should be stored, is that anyone writing an application using rvg's reads will also be able to take advantage of anybody else's app that exported reads in the same standard.

Like I said I don't know much about xml and if we would have to include a blank field for players with no read data, then I withdraw everything I just said.


[/ QUOTE ]
If we are to do this, then it must not be via an attribute, that leaves us far too few options as we can't even allow CDATA in there. I propose that we add a <metadata> element to the hand of type CDATA. This metadata section could then include any number of XML structures, delimited text or whatever, containing the reads, meta instructions and so forth. That'll be an optional element and any parsers can simply ignore that element unless they have a reason not to.

[ QUOTE ]
I'm kinda sympathetic to Shoe Lace's memory concerns. I'd like a won/loss summary mainly because I think it is a good check to make sure both the xml convertor and the app reading the xml output have performed correctly. But if we implement it there's no need to have a separate summary section. Can't we just add a field to the player info at the start of the hand.

We'd have:-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0" won="-10.8"/>

That shouldn't be more than 100 bytes added for a 9 player game.

[/ QUOTE ]
This is a good idea. There is no reason the summary information should be at the end of the hand, we can simply include it at the top. Adding things like won="true/false" and net="2492" would not take up much space and that is very valuable summary information.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
I suggest not using floats/doubles for amounts and simply use the lowest currency unit. For example in dollars, everything would be expressed in pennies.

[/ QUOTE ]

This seems very interesting and probably proper suggestion. I understand if application uses float numbers then all over the place amounts like 24.52 often would become 24.51999999 and 11.5 become 11.4999999 . So it is much clearer always to have integers 2452 and 1150 in pennies. And to have it in application this way from the very beginning -- from HH itself, without any overhead conversion.

[/ QUOTE ]
I agree, that would also spare us for a lot of trouble regarding decimal numbers using commas and periods in different ways.

[OrcaDK]

[ QUOTE ]
Muppet,

I do not like your approach to this hand history as it is simply not what we want. We want a PokerHandXML which describes the hand history of a single poker hand (or multiple poker hand but in isolation). We are not creating PokerTournamentXML (which can be developed as an extension - much like PokerMetaHandXML which includes stats and more.

The idea that I have in my head is that this should describe only one hand in isolation and not care about anything else. Thats for the applications to worry about. I do see a number of extensions coming from what we develop here though, and it seems as though we've already started them.

[/ QUOTE ]
I agree. Let's KISS. We ought to concentrate on creating a standard for a pokerhand, not a pokergame, not a whole tournament and so forth. As Tickner suggests, after this standard has been made, anyone can create their own <tournament> structure that includes several individual hands.

[Tickner]

TSchauenberg,

Yes and active player is a player that receives cards.

Real good point on the blind/ante allin situations.

Not sure what you meant about the deals?

Raising:

playerA bets $50, playerB raises to $150

<action type="bet" playerid="playerA" amount="50" />
<action type="raise" playerid="playerB" amount="150" />

I am saying that a raise should be the amount you raise to instead of the amount that is over the current bet (I think we all agreed on this I was just makign the point in the comments of the xml to be clear).

So we do the above INSTEAD of blow..

<action type="bet" playerid="playerA" amount="50" />
<action type="raise" playerid="playerB" amount="100" />

I still think that returning bets should be done as an action during a round. A player who has an uncalled bet is always returned that bet on the same street that the bet is uncalled and never at showdown.

Total Pot = Pot to player + Rake
so
Rake = Total Pot - Pot to player

I think total pot should include the rake. So you are right, if you add up the amounts given to each player and then add the rake you get the value in <pots value="x">

NOTE: I don't know if I am going to be able to work on a new version until Monday. I have work to do today and then tomorrow I got on a trip for the weekend. Perhaps somebody can take what I have right now and tweak it to work for all games?

[Tickner]

<font class="small">Code:</font><hr /><pre>
&lt;pots value="y" rake="b"&gt;
&lt;pot number="1" value="x1" winner="Tickner" /&gt;
&lt;pot number="2" value="x2" winner="durrr" /&gt;
&lt;/pots&gt;
</pre><hr />

what I mean by the rake is that using the values above:

y = b + sum(x)

So each pot adds up to the total amount given to each player

Once you add them up you can add the rake to get the toal pot size.

Think of it like this: rake is a small pot itself that the poker room "wins" by default.

[Phil153]

Random comments:

- Don't like the idea of raise TO. For each action, simply have the amount of money that's put in by that person during that action. That way the hand is agnostic to your description of the action (bet, raise, call). Stars really screws this up, and it's not the way most poker sites do things.

- Dislike the integer/cent representation. It's confusing to people casually browsing the hand and not intuitive. Is 2575 $25.75 or $2575? Since it's stored as text anyway, the issues with double precision are left as an exercise for the programmer, and nearly everyone who's going to use XML will have decimal data types available. If they're going to run into trouble parsing to doubles, they're going to run into trouble dividing by 100 to get the actual $ value.

- We're not in a hurry here. Let's take our time and see if we can't get it right the first time, get developers like PokerAce/PokerTracker to have some meaningful input, and get a good consensus on things. Tickner et al have done enough already that this will get finished in a few weeks. The only person pressing this is rvg and he's partly representing his own financial/workload interests.

[rvg72]

[ QUOTE ]
The only person pressing this is rvg and he's partly representing his own financial/workload interests.

[/ QUOTE ]

ummmm....lol??? All I've said is that if it is done relatively quickly I'd be able to get it in the beta and provide a sample conversion app and I've suggested we choose a couple of people to collaborate on the first draft so that we don't have 78 people pulling this in different directions.

Whether this is finalized tomorrow or next month doesn't change my financial or workload interests..

rvg

[TSchauenberg]

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
Likewise, should we not include who won the hand and who lost?

[/ QUOTE ]

To figure that out would require some type of hand rank chart code. Definitely not a good idea, it makes things overly complicated for everyone.

[/ QUOTE ]
Not including who won the hand is a very big mistake imho. It would not require any hand rank chart! The application creating these XML files is converting from the pokersite format - and those already include who wins and who looses, it'd be a simple matter of transferring that to an attribute. No calculation is done neither place.

[ QUOTE ]
[ QUOTE ]
and it'll save the importing application a lot of time if it's primarily interested in the net values

[/ QUOTE ]

How do you figure? You are severely underestimating the speed at which a CPU can calculate.

A developer's GetAmountWon() or GetPotSizeOnStreet(x) methods would be doing math like...

totalPot = a + b + c + d

Trust me, CPUs know how to count fast. The amount of time it takes to do this type of math on the fly is pure jokes.

[/ QUOTE ]
Now this is some funny stuff. You cannot compare iterating integers to parsing the XML file, taking care of all player actions, counting the pot together, deducting rake, jackpot amounts and so forth. The thing is that that requires some serious code to parse the XML and count the sum, there is absolutely no reason for the converting application not to do this along the way as is required anyways.

And if you think I'm talking about speed, you're dead wrong. I'm talking about code complexity.

[/ QUOTE ]

This was my point about nets being included in summary information. This calculation is pretty much Parser-complete in terms of parsing complexity so IMO it is a shame to throw all this hard work away especially when the benefits are so large to outside apps. From the way things are going, it looks like this will have to wait till the extended hand version, but I really can't stress how much this would help 3rd party app developers (for example, anyone could create a cool high stakes web db with this summary section alone).