Poker Hand XML - Page 16

OrcaDK · #**151** 08-02-2007, 04:10 PM

[ QUOTE ]
Sorry, I only read the first 5 posts but has the possibility of using an XML database instead of SQL been discussed?
Could be interesting.

[/ QUOTE ]

No, we are not trying to come up with a database format, not even if it's XML based. The whole idea is still to come up with a standardized XML hand format. After this, people can implement all the proprietary storage means they wish.

Shoe Lace · #**152** 08-02-2007, 04:12 PM

[ QUOTE ]
I would like to include some summary information as well. Not a whole summary section, just a net win/loss for each player at the end, also recapping the current stack.

[/ QUOTE ]

Why do so many people want this? You understand that by adding 250 characters or so to a hand that you're looking at a little over 250mb of space over 1m hands?

A few line method that does 2nd grade math pretty much instantly is clearly the better choice. Plus it fits into the "hi, I'm a hand history and I'm telling you the story. If you're reading me you'll be able to figure everything out and draw your own conclusions" theme.

Edit: I'd almost go as far as saying the SB and BB values defined up top with the other game information isn't needed. If the dealer button is defined, then it wouldn't be difficult to figure out what the SB and BB values are. This might be going a bit overboard though.

advis0r · #**153** 08-02-2007, 04:21 PM

if you care about 250mb with 1 m hands, you shouldnt be using XML.
250 chars is prolly estimated too big anyway.
also, as mentioned earlier in this thread, there's good text compression available [img]/images/graemlins/smile.gif[/img]

OrcaDK · #**154** 08-02-2007, 04:22 PM

[ QUOTE ]
Why do so many people want this? You understand that by adding 250 characters or so to a hand that you're looking at a little over 250mb of space over 1m hands?

A few line method that does 2nd grade math pretty much instantly is clearly the better choice. Plus it fits into the "hi, I'm a hand history and I'm telling you the story. If you're reading me you'll be able to figure everything out and draw your own conclusions" theme.

[/ QUOTE ]

I don't really see storage as an issue (within reason), this format is not meant to be used as permanent hand storage, simply a measure to translate hands between systems. Text compression is extremely capable, on average resulting in about 90% compression. 250MB ~= 25MB, that's not too much for 1m hands, especially considering that you'd probably rarely transfer 1m hands at a time in this format (although I admit it's worth considering!).

Since we'll probably allready have a <showdown> like section containing each players showdown hand/cards/value, it'd just be a matter of adding a net="25,35" attribute containing the net won amount.

chipwiz · #**155** 08-02-2007, 04:27 PM

[ QUOTE ]

Edit: I'd almost go as far as saying the SB and BB values defined up top with the other game information isn't needed. If the dealer button is defined, then it wouldn't be difficult to figure out what the SB and BB values are. This might be going a bit overboard though.

[/ QUOTE ]

There are situations where there is no small blind (e.g. when player that should have the small blind is sitting out or left the table). I think there may be more situations of this where having the parser "figure it out" can cause problems.

Shoe Lace · #**156** 08-02-2007, 04:36 PM

[ QUOTE ]
250 chars is prolly estimated too big anyway.

[/ QUOTE ]
Actually the summary from a 9 handed hand on stars without a showdown is closer to 500 bytes. This doesn't even include their net win/loss. With a showdown and trimming a few things out I think 250 bytes is extremely generous. I'd say 350 seems reasonable.

[ QUOTE ]
I don't really see storage as an issue (within reason), this format is not meant to be used as permanent hand storage, simply a measure to translate hands between systems. Text compression is extremely capable, on average resulting in about 90% compression. 250MB ~= 25MB, that's not too much for 1m hands, especially considering that you'd probably rarely transfer 1m hands at a time in this format (although I admit it's worth considering!).

[/ QUOTE ]

It's a lose/lose situation. You are avoiding logic and countering my statements with completely irrelevant facts.

1. It's taking up more space. <-- bad
2. It's putting evaluations into something that should be storing hands. <-- bad
3. You are taking up more resources because you have to write extra data. <-- bad.

If we assume the app is going to read the XML hand, then import the pieces into the db it could add the pot sizes and summaries here (this only has to be done once when the hand is physically imported).

OrcaDK · #**157** 08-02-2007, 04:50 PM

[ QUOTE ]
It's a lose/lose situation. You are avoiding logic and countering my statements with completely irrelevant facts.

1. It's taking up more space. <-- bad
2. It's putting evaluations into something that should be storing hands. <-- bad
3. You are taking up more resources because you have to write extra data. <-- bad.

If we assume the app is going to read the XML hand, then import the pieces into the db it could add the pot sizes and summaries here (this only has to be done once when the hand is physically imported).

[/ QUOTE ]

It's a matter of evaluating the importance of the data versus the extra overhead. If we already have a summary section and adding the net values is simply a matter of adding an attribute, I see no reason not to add it. It's something every converter will have knowledge of at the time of creation, and it'll save the importing application a lot of time if it's primarily interested in the net values. Likewise, should we not include who won the hand and who lost? Should we not add and attribute allin="true" when a player raises/calls all in? These are all examples of things that are evaluations that could be parsed from the HH, but it's so easy for the converter to add these pieces of information. Although the primary purpose of this standard is to allow transition of hands from format to format, there's no real reason not to help a bit by providing the simplest of data along the way. As long as there are no ambiguous datatypes and values.

If on the other hand we don't have a summary section, I agree we should not add one for this one purpose alone.

I'm off to bed, I'll look back tomorrow.

MuppetBingo · #**158** 08-02-2007, 04:52 PM

Here's version 1.4, this is a real Pacific Poker hand converted. Pacific Poker doesn't show the rake, so I have hand calculated it. I could have miscalculated, but it would seem that they rake empty sidepots.

Inspired by Shoe Lace's example, I tried to make the format a little less verbose.

A bunch of attributes have been moved around or renamed, and I've introduced an element to contain a cashgame-session of pokerhands or a whole tournament. I don't have any tournament hand histories though, so if anyone want to try to hand-convert a tournament hand or two to this format, and make the <tournamentsummary>, that would be most welcome.

<font class="small">Code:</font><hr /><pre>
<?xml version="1.0"?>
<pokerxml>
<cashgame>
<cashgamecontext site="Pacific Poker" online="true" currency="USD"/>
<pokerhands>


<pokerhand id="157430484" timestamp="03 30 19:05:56 2007" gametype="holdem" bettingtype="nolimit" smallblind="2" bigblind="4">

<table id="Fuzzy Navel" seats="10" dealer="5">


<seat id="10" name="gmac84" stack="551.9" active="true" ante="0"/>
<seat id="4" name="regi111" stack="328.65" active="true" ante="0"/>
<seat id="5" name="musti455" stack="96.3" active="true" ante="0"/>
<seat id="7" name="koraaf" stack="359.8" active="true" ante="0"/>
<seat id="8" name="MuppetBingo" stack="400" active="true" ante="0"/>
<seat id="9" name="Ls1972" stack="262.97" active="true" ante="0"/>
</table>
<rounds>


<round order="0">

<deals>

<deal seat="4" open="false">
<cards>
<card value="8" suit="s"/>
<card value="9" suit="c"/>
</cards>
</deal>
</deals>
<actions>



<action seat="4" type="post" amount="4"/>
<action seat="7" type="smallblind" amount="2"/>
<action seat="8" type="bigblind" amount="4"/>
<action seat="9" type="fold"/>
<action seat="10" type="fold"/>
<action seat="4" type="check"/>
<action seat="5" type="call" amount="4"/>
<action seat="7" type="call" amount="2"/>
<action seat="8" type="check"/>
</actions>
</round>
<round order="1">
<deals>

<deal open="true">
<cards>
<card value="9" suit="s"/>
<card value="a" suit="c"/>
<card value="a" suit="s"/>
</cards>
</deal>
</deals>
<actions>
<action seat="7" type="check"/>
<action seat="8" type="bet" amount="4"/>
<action seat="4" type="fold"/>
<action seat="5" type="call" amount="4"/>
<action seat="7" type="fold"/>
</actions>
</round>
<round order="2">
<deals>
<deal open="true">
<cards>
<card value="a" suit="h"/>
</cards>
</deal>
</deals>
<actions>
<action seat="8" type="check"/>
<action seat="5" type="bet" amount="4"/>
<action seat="8" type="raise" amount="392"/>
<action seat="5" type="call" amount="84.3"/>
</actions>
</round>
<round order="3">
<deals>
<deal open="true">
<cards>
<card value="q" suit="h"/>
</cards>
</deal>
</deals>
<actions>

</actions>
</round>
</rounds>
<result>
<hands>

<hand seat="5">
<cards>
<card value="k" suit="d"/>
<card value="9" suit="d"/>
</cards>
</hand>
<hand seat="8">
<cards>
<card value="8" suit="s"/>
<card value="9" suit="c"/>
</cards>
</hand>
</hands>

<pots rake="4" jackpot="0">

<pot>
<collect seat="5" amount="98.3"/>
<collect seat="8" amount="98.3"/>
</pot>

<pot>
<collect seat="8" amount="303.7"/>
</pot>
</pots>
</result>

</pokerhand>
</pokerhands>
</cashgame>
<tournament currency="USD" buyin="10" vig="10" id="123123" name="150K Guaranteed">
<pokerhands>

</pokerhands>
<tournamentresult>

</tournamentresult>
</tournament>
</pokerxml>
</pre><hr />

chipwiz · #**159** 08-02-2007, 05:32 PM

[ QUOTE ]
Here's version 1.4, this is a real Pacific Poker hand converted.
...

[/ QUOTE ]

Very nice. I've tried to find anything wrong with it, but you seem to have put thoughts into everything [img]/images/graemlins/smile.gif[/img]. Having a <cashgame>/<tournament> context felt a bit out of scope at first but I guess if you want to store tournament summaries etc. it is necessary. Just one thing I would prefer the posting of antes to be an pre-flop action just as the posting of the blinds.

Shoe Lace · #**160** 08-02-2007, 05:47 PM

[ 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 ]
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.

I wrote a small application that does the following:

<font class="small">Code:</font><hr /><pre>
double x = 0;
int r = 1000000;

watch.Start();

for (int i = 0; i < r; i++)
{
x += i;
}

watch.Stop();
</pre><hr />

This code loops 1 MILLION TIMES. Inside each loop it's doing "x = x + i".

The result? 6 or 7 milliseconds for each iteration.

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

totalPot = a + b + c + d

Calculations like this don't even register 1 millisecond (although this could be a bug with the StopWatch class as I haven't worked with it before today, but the big loop was giving consistent results every time).

Did I mention the computer that's running it is a 3.5 year old P4 3.0 with 1 GB of ram, hasn't been rebooted in almost 2 weeks, and is running a large amount of applications in the background.

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.