PDA

View Full Version : Enter the SECT



Ggrognon
08-28-2009, 01:59 PM
Hello,

I am a french poker player, but also a nerd sometimes. My poker nickname is Pprofesseur. With the help of another french poker player Victor118, I developped a tool called SECT : Showdown Equity CalculaTor.

I needed a tool to show me what should have been my winnings at Showdown without those f****** bad beats. I reminded myself of PokerEV tool (when I used to have PT2). It was cool to see my real winnings vs my expected winnings.

HEM gives you all-in EV at the street it went all-in. But it does not calculate your EV street by street. I then decided to do such a tool for me. I also decided to analyze not only all-in situations but *all* showdown hands. I developped such a tool. Usable only by me (a lot of manual code configurations were needed to make it work). It was so interesting (on my point of view and my poker friends) that I thought it might be helpful for a lot of poker players. But I had to make major changes to make it work for everybody. I dit it too (it took a lot of time).

SECT is written in JAVA to male it work on quite any platform (I hope so).

SECT is for HEM users. SECT reads the database created and filled by HEM to find hands and analyze them. Why HEM and not another tracker database ? I use HEM, so I developped for it. Maybe one day I will adapt SECT for other databases too, we'll see...

SECT analyzes only cash game NLHE hands. It was a big job to write a pokerstove-like in JAVA for Holdem hands, and I don't plan to do the same job for other types of poker in the short run.

---

RELEASE SECT 3.2.7

Previous version was v3.2.6.

What is new in 3.2.7 (compared to 3.2.6) :

[BUG] There was a major issue : the more hands SECT was parsing, the slower it was. It used to freeze sometimes depending on the sample size. This is now corrected.
[IMPROVEMENT] Speed is a little bit increased.
[IMPROVEMENT] Graph default sized increased to avoid having to resize. Resizing graphs for big samples may be difficult (the drawing is redrawn and resource consuming). Graph is not made directly by SECT but by a library we use.



Important :

SECT is only for Cash-Game hands in No Limit Hold'Em.
SECT is only for HEM users (SECT reads the database written by HEM).


Upgrade from SECT 3.2.6 (previous version) to SECT 3.2.7 :

Go there : http://www.sect.free.fr
Download 3.2.7 .jar file
Put 3.2.7 .jar file where you had 3.2.6 .jar file and use this new one instead.
... that's all !


Doawload and install SECT for the first time :

Here : http://www.sect.free.fr
Download version 3.2.7 of .rar file
Uncompress .rar in a dedicated folder for SECT
Edit (once for all) the .xml file

Replace "HoldemManager" by the name of your database if different
Replace "postgres" by your postresql login if different
Replace "postrepass" by your postgresql password if different
... It's done !

Double-clic on .jar file (SECT_v3.2.7.jar).

If it runs, great !
If the file is opened within a decompression tool (unzip, unrar, ...) it means your computer does not know how to handle .jar files. I advise to download and install the latest JRE (JRE 6 update 16 (http://java.sun.com/javase/downloads/index.jsp)).



Be aware :

If you parse a very large amount of hands, at the end of the computation, SECT asks a library (not coded by me) to draw the graph. If you have a huge sample, the graph drawing may take a very long time. You will see an empty window while it is computing the drawing. SECT is not freezing. Just be patient. If you have 200K hands, there are 200K points to draw, and multiply this by the number of lines.
When you leave blank start date, SECT understands you want to start with the very first hand in time. When you leave blank end date, SECT understands you want the hands until the last one in time.
SECT computation is not instantaneous. I made the choix to develop all of this stuff in JAVA for portability reasons. I did not used the optimized librairies freely available for equity computation, but which are (quite) not (easily) portable. I rewrote evrythig in JAVA. Then everybody can use SECT. Computation is not very fast, but when you parse hands that you have already parsed before, you'll see that the computation is faster. Please note that I am thinking of a new version where once you've parsed a hand, the next time you do it again, it is quite instantaneous.
Computation time is of course machine-dependent.
HEM team is aware of the following : some Ongame play money hands are considered by HEM as real money hands... so does SECT, because SECT uses HEM database.
It is good to stress this next point. SECT modifies nothing in your HEM database. SECT just reads this database, so it should be harmful.
SECT makes women fertile, SECT makes men potent, SECT makes children good at school.
What are these "corrupted SDs" ? SD = ShowDown. In HEM database, some showdown hands do not have hole cards for all the players who went to showdown. SECT is then enable to do its equity computation. FYI, corrupted SD hands are often the result of a HH change done by the pokerroom, before HEM updates to take this new HH grammar into account.
If you wrongly configure the .xml file, nothing will happen when you launch SECT. Infortunately you'll see no warning message. I did not yet manage to handle this error. If you really want to know for sure if your problem is due to the .xml file configuration just launch SECT from the DOS command line. You'll see the errors messages.
I do not advocate using SECT while playing poker and using HEM to grab hands and diplay HUD. To be honest, I did no test about that, and I say that as a precaution. One tool (HEM) writes in the database, while another one (SECT) reads it, so It should be ok. Anyway, SECT is a tool you will mainly use after having played.
After computation, there is sometimes an expected auto-resize of the graphical interface. I am still trying to find why. Just resize the window and it is ok.


Wish list for future releases :
(I intend to go back to poker and develop less, you should take this into account ;) )

Let user choose if he wants a graph or not (graph drawing may be very long on huge samples)
Change graph colors.
Check other types of corrupted showdowns.
It is sometimes difficult to resize the graph window when there are multiple lines.
Handle the error when user wrongly configures the .xml file
SECT does not recalculate a hand it has already computed. New parsings would only compute new hands.
Choose date on a calendar.
Chosse hour for dates
Limit Holdem.

Ggrognon
08-28-2009, 02:02 PM
(delete me)

DonManuel
08-30-2009, 04:14 PM
I still wonder why this is not built-in in HEM...

Ggrognon
08-30-2009, 06:04 PM
Yes I was wondering too, then I did it because I was too unlucky and I needed to prove it ! :D


For information : I got now my 10 beta-testers. Already 2 new (private / beta testers only) releases. Things are going better and better. I will let you all know.

klausschreiber
08-31-2009, 02:02 PM
sounds very nice. I hope, it will be public soon.:)

Mon
09-01-2009, 01:29 PM
Looks really good. I was a betatester when Phil's started PokerEV, mainly testing Crypto hands (where I used to play). Please let us know when this will be available as soon as you can, cannot wait to run it!! ;)

Ggrognon
09-01-2009, 04:00 PM
I got my pool of ten beta-testers.

I've already done two corrective versions.

Things are going well, but step by step : I got a job, a couple life and try to play poker too ;) .
My testers too, though we miss one each other very often.
I will let you know when it is ok.

For the moment, following first tests, what I can say is :
- everybody was able to launch it very easily : easy configuration and portable.
- found one major issue : SECT did not handle multiple accounts on different rooms with the same name. Now it is corrected.
- I got one tester who did not manage to run SECT : I will try to see that with him via skype/teamviewer.
- received different proposal for future evolutions.

zenopyan
09-02-2009, 06:46 AM
Looking forward to it :)

JPFisher55
09-05-2009, 11:33 AM
I'm really looking forward to this program. I expect my EV winnings to exceed my real winnings because if my opponent had a draw and folded on the river, then I will never know that my hand held up. OTOH, if my opponent hits a draw, then a showdown is more likely. So I will see more times that my opponents outdraw me than they actually do outdraw me; even though sometimes I will fold a hand when I believe that my opponent hit his hand and not know for certain.

Still, IMO, if my luck is average then my EV winnings should not exceed my real showdown winnings by more than 20%; otherwise I will know that I am unlucky.

Ggrognon
09-06-2009, 03:49 AM
Hello,

I have released SECT v3.2.4. You will find all the details in the first post (I have edited it).


Have fun... and run good !

Mon
09-06-2009, 06:26 AM
Thank you for posting the link! I'm eager to try it!

JPFisher55
09-06-2009, 12:47 PM
Can it take over one hour to parse hands for a player with over 100,000 hands played? I can get the program to run with players who have 10-30k hands, but for players over about 70k hands, the program just sits with the parsing hands with no SD hands or time to complete calculated even if I let it run for over one hour.

SarahSugar
09-07-2009, 04:42 AM
Can it take over one hour to parse hands for a player with over 100,000 hands played? I can get the program to run with players who have 10-30k hands, but for players over about 70k hands, the program just sits with the parsing hands with no SD hands or time to complete calculated even if I let it run for over one hour.

Same Problem here.

Additionally: I would love to have the Option, to select an "Alias",
since I am playing on 4 different Poker Plattforms.

So I could create a graph for all 4 plattform and not each one alone.


Keep up the good work.
Regards

Sarah

Mon
09-07-2009, 06:01 AM
Can it take over one hour to parse hands for a player with over 100,000 hands played? I can get the program to run with players who have 10-30k hands, but for players over about 70k hands, the program just sits with the parsing hands with no SD hands or time to complete calculated even if I let it run for over one hour.

Same problem here, can't make it work if I use dates from last year (don't know if a problem with date filter or too many hands).

klausschreiber
09-07-2009, 04:19 PM
I also had problems, but it helped to restart the program and to try it again.

JPFisher55
09-07-2009, 04:45 PM
By calculating one month at a time, I got the program to work for players with lots of hands. Remember the day of the month is first and the month second. If you reverse these, the program freezes.

However, if you leave the dates blank, then the program freezes with players with many hands. I think it freezes if the number of SD's exceeds 999, but I'm not sure.

Ggrognon
09-08-2009, 12:11 PM
Ok... here is a status :

1/
When you leave start date blank : it considers "the first hand"
When you leave end date blank : it considers "last hand"

2/
French date format : dd/mm/yyyy
One modification in my todo-list is : choose date using a date chooser ==> there will be no more "country date format issue".

3/
SECT freezes.
I found why SECT sometimes freezes at "Parsing..." point without doing anything.
JAVA puts a limit (of 2 Mo I believe) for the memory a Java program uses.
When the number of hands is big (this "big" depends on the machine), you can shoot this limit. When it occurs, JAVA throws an error, and program freezes.
I have imagined an new algorithm to avoid this issue. It is not yet coded. It is for the next SECT version. You will then be able to parse any amount of hands (as big as you want).
I will let you know here when this new version is available.

4/
Using aliases instead of just one screenname.
I have recorded this request.
It is now in my todo-list for future versions.

JPFisher55
09-08-2009, 12:44 PM
Ok... here is a status :

1/
When you leave start date blank : it considers "the first hand"
When you leave end date blank : it considers "last hand"

2/
French date format : dd/mm/yyyy
One modification in my todo-list is : choose date using a date chooser ==> there will be no more "country date format issue".

3/
SECT freezes.
I found why SECT sometimes freezes at "Parsing..." point without doing anything.
JAVA puts a limit (of 2 Mo I believe) for the memory a Java program uses.
When the number of hands is big (this "big" depends on the machine), you can shoot this limit. When it occurs, JAVA throws an error, and program freezes.
I have imagined an new algorithm to avoid this issue. It is not yet coded. It is for the next SECT version. You will then be able to parse any amount of hands (as big as you want).
I will let you know here when this new version is available.

4/
Using aliases instead of just one screenname.
I have recorded this request.
It is now in my todo-list for future versions.

I wouldn't worry about the French dating system. Once you get used to it, then it is no problem. The memory needs expansion. The aliases would be nice, but not critical.

I have some hands from last year that are converted Cake into Poker Stars hands. Some of their SD's are corrupted. Once in a while the program will freeze on a corrupted SD. If it does, then it cannot complete that month even with multiple efforts.

Ggrognon
09-08-2009, 01:15 PM
I have some hands from last year that are converted Cake into Poker Stars hands. Some of their SD's are corrupted. Once in a while the program will freeze on a corrupted SD. If it does, then it cannot complete that month even with multiple efforts.


This is a new issue to me.
It will be interesting to see if this issue remains once I've fixed the "SECT freezes" issue.

SarahSugar
09-10-2009, 03:19 PM
Ok... here is a status :

1/
When you leave start date blank : it considers "the first hand"
When you leave end date blank : it considers "last hand"

2/
French date format : dd/mm/yyyy
One modification in my todo-list is : choose date using a date chooser ==> there will be no more "country date format issue".

3/
SECT freezes.
I found why SECT sometimes freezes at "Parsing..." point without doing anything.
JAVA puts a limit (of 2 Mo I believe) for the memory a Java program uses.
When the number of hands is big (this "big" depends on the machine), you can shoot this limit. When it occurs, JAVA throws an error, and program freezes.
I have imagined an new algorithm to avoid this issue. It is not yet coded. It is for the next SECT version. You will then be able to parse any amount of hands (as big as you want).
I will let you know here when this new version is available.

4/
Using aliases instead of just one screenname.
I have recorded this request.
It is now in my todo-list for future versions.


Sounds really good ;)
Hope for the new version soon.
I shipped you some bucks on fulltilt. I appreciate your work a lot!

Keep on rocking

Ggrognon
09-11-2009, 02:56 AM
Sounds really good ;)
Hope for the new version soon.
I shipped you some bucks on fulltilt. I appreciate your work a lot!

Keep on rocking

Here is a nice guy ! Thanks a lot ;). It is great to receive some $ saying "thank you".


FYI, I've coded SECT 3.2.5 to correct "freezing bug" (see point 3 above).
It is now being tested.

SarahSugar
09-11-2009, 01:57 PM
Hehe ;)
You are very welcome.

i think you could easily make the programm shareware, if you would like...
many people are interested in such software , but i guess thats an other topic.

have a good day.

Ggrognon
09-16-2009, 03:18 PM
SECT 3.2.6 RELEASE

Previous version was v3.2.4.

What is new in 3.2.6 (compared to 3.2.4) :

[BUG] For some users, SECT did freeze at the beginning of the parsing. Especially when the number of hands to parse was big. It is now corrected. You can parse any amount of hands.
[BUG] SECT was adding winnings of corrupted showdown hands to "non-showdown winnings". It is now corrected. Showdown winning (either corrupted or not) are added together.
[IMPROVEMENT] New information on SECT GUI after computation : total actual winnins, total expected winnings, total non-showdown winnings.
[IMPROVEMENT] ETA computation was changed. No impact for user.
[IMPROVEMENT] GUI management was changed. No imapct for user.



----

I have edited first post. Everything is explained in it. Please read it carefully as I have checked and edited each section accordingly.
Everything is expl

JPFisher55
09-16-2009, 05:45 PM
I tried the new version, but it freezes after starting to parse a large amount of hands.

Ggrognon
09-16-2009, 06:02 PM
I tried the new version, but it freezes after starting to parse a large amount of hands.

Is it freezing before having parsed one single hand ? Or after having parsed some hands ?

Can you execute SECT from the DOS command line, you will get error messages. I would like to have a look at them.

Just do the following : go into your dos command line (depends on your operating system), go into your SECT directory where your .jar file is, then type : java -jar SECT_v3.2.6.jar
It does the same thing as if you double-click on the .jar file, but you will see messages in the dos window and if any, error messages. Can you copy paste them to me (private message) ?

JPFisher55
09-16-2009, 06:23 PM
It freezes after many SD's; like over 1500. It starts out fast, slows, slows some more, crawls and then finally stops. I'll follow your instructions and PM you the results later today.

JPFisher55
09-16-2009, 08:41 PM
Is it freezing before having parsed one single hand ? Or after having parsed some hands ?

Can you execute SECT from the DOS command line, you will get error messages. I would like to have a look at them.

Just do the following : go into your dos command line (depends on your operating system), go into your SECT directory where your .jar file is, then type : java -jar SECT_v3.2.6.jar
It does the same thing as if you double-click on the .jar file, but you will see messages in the dos window and if any, error messages. Can you copy paste them to me (private message) ?

I tried running this command, but my computer does not recognize it. I do have the latest java program installed.

Ggrognon
09-17-2009, 01:31 AM
It freezes after many SD's; like over 1500. It starts out fast, slows, slows some more, crawls and then finally stops. I'll follow your instructions and PM you the results later today.

This is not the "freezing bug"... but it is anew one. Sick.


I tried running this command, but my computer does not recognize it. I do have the latest java program installed.

Have you tried installing JRE(*) as explained in the first post ? It should then recognize "java" command after installation. Be aware to install the good JRE (follow link in 1st post, and download JRE corresponding to your operating system).



(*) JRE : Java Runtime Environment. It is a Sun Microsystem product. Sun created Java.

JPFisher55
09-17-2009, 10:55 AM
Yes, I have JRE installed.

Mon
09-17-2009, 02:46 PM
It freezes after many SD's; like over 1500. It starts out fast, slows, slows some more, crawls and then finally stops.

Same problem here.

Ggrognon
09-17-2009, 06:28 PM
Same problem here.

Could you launch SECT from windows dos command line ?

typing from SECT directory : java -jar SECT_v3.2.6.jar


And copy paste to me in a private message the error messages ? I need them to find the problem.

Mon
09-18-2009, 03:22 AM
Could you launch SECT from windows dos command line ?

typing from SECT directory : java -jar SECT_v3.2.6.jar


And copy paste to me in a private message the error messages ? I need them to find the problem.

PMed. It freezed after 66% aprox. with 1807 goos SD parsed.

melles
09-18-2009, 02:25 PM
Thnaks you verry much nice work, I have been looking for something like this for a long time.

Ggrognon
09-18-2009, 02:45 PM
Thnaks you verry much nice work, I have been looking for something like this for a long time.

Keep in touch with this thread. I announce releases here.

I should release soon a 3.2.7 version which corrects the bug : the more hands are parsed, the more SECT slows down (and freezes).

TheSickest
09-18-2009, 04:01 PM
This guy is clever and his software is the real EV ajusted which the most players misuse everyday.
You deserve $$$

bakamor
09-18-2009, 11:40 PM
This guy is clever and his software is the real EV ajusted which the most players misuse everyday.
You deserve $$$

QFT I hope the bug gets fixed soon

Mase31683
09-19-2009, 10:27 PM
First of all, thank you sooooooo much! Can't stress enough how much having this makes me love life.

But I have to ask a stupid question, lol.

On every single level, I'm running sickly under my EV. Is this:

1) A function of my generally TAGish play?

2) Just standard variance?

3) Somehow related to how the program is written?

The only reason I even bring up #3 is from the OP stating you needed to "prove how bad you ran" or something to that effect, lol. I don't have many hands on other players to run a significant graph, so could others maybe just let me know if they're running close to EV, or even above?

Thank you so much again, and +1 on you should be paid for this feature!!! I'm a micro grinder, but if I ever start to catch up to where my EV says I should be, I am definitely shipping you some bux for your work! :)

Ggrognon
09-20-2009, 03:59 AM
First of all, thank you sooooooo much! Can't stress enough how much having this makes me love life.

But I have to ask a stupid question, lol.

On every single level, I'm running sickly under my EV. Is this:

1) A function of my generally TAGish play?

2) Just standard variance?

3) Somehow related to how the program is written?

The only reason I even bring up #3 is from the OP stating you needed to "prove how bad you ran" or something to that effect, lol. I don't have many hands on other players to run a significant graph, so could others maybe just let me know if they're running close to EV, or even above?

Thank you so much again, and +1 on you should be paid for this feature!!! I'm a micro grinder, but if I ever start to catch up to where my EV says I should be, I am definitely shipping you some bux for your work! :)

First, I'd like to thank you for you congratulations. Yeah it really took me time to develop this. And I am still developing it. So it still takes me time. I am a player playing few hands. Coding SECT makes me play fewer hands. That is why I appreciate when users send me money. Whatever amount (even one buck :D) is fine (as said in the GUI). It is a nice way to say thank you ;) .

Before answering to your interesting post, I must recall that there is an issue with SECT (version 3.2.6 or previous). The more hands you parse, the slower SECT becomes. It may even stop and freeze. I am working on fixing this bug. I have found a good solution, but there are side effects. I am working on fixing side effects to deliver asap a 3.2.7.

Back to your post now.
I would like to see a post of a "specialist" explaining how to interpret those graphs. Do not hesitate. I am not a specialist, but here is what I can say (it may be wrong). Each time I've seen the result of SECT for good players, graphs have the same "look". Expected winnings at SD (=[Exp]) is climbing, always. Actual winnings at SD (=[Act]) are under the expected winnings this way : [Act] follows the [Exp]. There is the same difference between the two. Regularly at some point, the difference between [Act] and [Exp] becomes bigger (==> bad beat) and after difference remains the same for next hands. And so on... Something like the following (this picture is hand made, as I am NOT a winning player and my graph is very different than this one, see later :eek:).

http://img35.imageshack.us/img35/296/handmade.jpg

How to interpret that ? My first feeling was that a good player "always" makes the good choices. So at SD, either he won what he should have plus the rest of the equity that is not for him (when you win AA vs TT, 20% of the pot is for Vilain). The difference between his [Act] and his [Exp] is becoming slightly less big for each of this hands. And regularly, because it is poker, Hero suffers a bad beat. And then the difference between his [Act] and [Exp] increases a lot for this hand. My analysis (I am not a specialist, I want to stress that again) is that a good player will never see his [Act] catch up with [Exp], but the overall is climbing and Hero is winning money.
OK, now that you have heard the analysis of a non-specialist :D, here is a post from a player who said something very interesting. He explained the graph he expected to see BEFORE using SECT. And this is the graph good players often see : http://64.77.69.66/forum/member.php?u=700 (http://64.77.69.66/forum/member.php?u=700).
I insist on the fact that I would like to have posts from people who can explain the way their graphs look like.


As I am concerned, my graph is not the kind I described above :( for good players . My [Exp] is diving into the ocean and [Act] is following [Exp]. Showing me that I am a losing player (it won't last, believe me !) and that it has nothing to do with bad luck. Even if I ran bad at the end, it is not a good graph. Even if you give me the missing bucks due to bad luck, I lose a lot. Now you understand the need to send me few bucks dear "users of SECT" to say "thank you for being a loser player and writing a tool to prove it !" :p

Coming out : here is my graph of all my NL100 hands which is where I play now (sample is not that big, I know I play few).

http://img30.imageshack.us/img30/6861/nl100w.jpg

JPFisher55
09-20-2009, 11:24 AM
I think I'm the poster who expected to have expected winnings exceed actual winnings. So far this has held for this month, but I'm up this month. So I thought that I would expand on my thoughts on this topic by relating my EXPWIN versus ACTUALWIN for the last two years which I have run by month.

To start, I have been playing since 2005. I won every year until this year and I am even this year. Last year at NL100-200, I averaged about 3 Big Blinds "BB" per 100 hands after rakeback. Last year most of months my EXPWIN slightly exceeded my ACTUALWIN. My Non-showdown losses were -12.37 BB/100 hands and my showdown winnings were 387.04 BB/100.

This year (through August) I have been in a long losing streak and am about even for the year. Most months my EXPWIN was slightly above my ACTUALWIN. More significantly, my Non-showdown losses are -16.5 BB/100 this year. IMO this is due to having to fold medium strength hands due to obvious scare cards hitting the turn or the river and facing large bets. My showdown winnings this year are 413.02 BB/100 hands.

I have concluded that the amount of Non-showdown losses indicates your luck more than EXPWIN versus ACTUALWIN. It would be nice if we had our Expected Winnings broken down by preflop, flop and turn. Then we could compare the rates for each street and tell when we were experiencing bad or good luck. In conclusion, your Non-showdown losses are the most important stat to examine your luck and your success. The lower, the better and the luckier you have been.

Ggrognon
09-23-2009, 06:21 PM
Release of SECT version 3.2.7

What is new in 3.2.7 (compared to 3.2.6) :

[BUG] There was a major issue : the more hands SECT was parsing, the slower it was . It used to freeze sometimes depending on the sample size. This is now corrected.
[IMPROVEMENT] Speed is a little bit increased.
[IMPROVEMENT] Graph default sized increased to avoid having to resize. Resizing graphs for big samples may be difficult (the drawing is redrawn and resource consuming). Graph is not made directly by SECT but by a library we use.



All details in first post.

Vampyr09
09-27-2009, 03:38 PM
I have the problem, that my database is named nl200/nl400.

So it stops by the / and only read the name nl200.

What to do?

Ggrognon
09-27-2009, 04:52 PM
I have the problem, that my database is named nl200/nl400.

So it stops by the / and only read the name nl200.

What to do?

I had the same pb with my previous database ... and I did not find the way to manage that. I log this, and will try to find a solution.

hardeerr
09-30-2009, 03:27 PM
For me, the program runs OK and says it successfully parsed my small database (2300 hands. all cash, all FullTilt), but after parsing it does not show anything (no graph, no report).

Am I doing something wrong?

Thank you.

Ggrognon
10-01-2009, 02:05 AM
For me, the program runs OK and says it successfully parsed my small database (2300 hands. all cash, all FullTilt), but after parsing it does not show anything (no graph, no report).

Am I doing something wrong?

Thank you.

1/ Did you get the right version ? For a moment, there was a version 3.2.7 in a debug directory with (done in purpose) no graph.
Do you have the 3.2.7 coming from the 3.2.7 folder ? If you are not sure, download the 3.2.7 jar file and replace the previous one.

2/ SECT works only with no-limit texas hold'em cash game hands.

3/ Try to launch SECT from the dos window : under the SECT directory type : java -jar SECT_v3.2.7.jar
You will then see error messages if any. Tell me what they are.

Fiftyfifty
10-01-2009, 07:00 AM
Hi. Your tool looks really good. but i miss the option to choose the alias to show all hands if you play at more than one site.

melles
10-02-2009, 09:13 AM
Hi. Your tool looks really good. but i miss the option to choose the alias to show all hands if you play at more than one site.
+1

hardeerr
10-02-2009, 04:52 PM
1/ Did you get the right version ? For a moment, there was a version 3.2.7 in a debug directory with (done in purpose) no graph.
Do you have the 3.2.7 coming from the 3.2.7 folder ? If you are not sure, download the 3.2.7 jar file and replace the previous one.

2/ SECT works only with no-limit texas hold'em cash game hands.

3/ Try to launch SECT from the dos window : under the SECT directory type : java -jar SECT_v3.2.7.jar
You will then see error messages if any. Tell me what they are.

Hi.

1. Yes, I got the RAR and followed the instructions exactly.

2. Yes, NLHE cash is all I have. It found all my hands, apparently.

3. OK, that gave me a whole bunch of error messages. So I reinstalled Java fresh from Java.com but still get there errors. Specifically:

log4j:WARN No appenders could be found for logger (org.springframework.core.Coll
ectionFactory).
log4j:WARN Please initialize the log4j system properly.
LUT2 not found : java.io.FileNotFoundException: LUT2 (The system cannot find the
file specified)
LUT3 not found : java.io.FileNotFoundException: LUT3 (The system cannot find the
file specified)
Loaded [0] learned equities.
Loading Time : 0h0min0s
playerID : 10
nb hands = 2259
compteur=2260
Chart : in money
Exception in thread "Thread-3" java.lang.ExceptionInInitializerError
at org.jfree.chart.ChartFactory.createXYLineChart(Cha rtFactory.java:1739
)
at com.gt.chart.ChartEV.createGraph(ChartEV.java:64)
at com.gt.service.CashGameHoldemService.analyse(CashG ameHoldemService.ja
va:2250)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknow n Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Un known Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.aop.support.AopUtils.invokeJoi npointUsingReflecti
on(AopUtils.java:310)
at org.springframework.aop.framework.ReflectiveMethod Invocation.invokeJo
inpoint(ReflectiveMethodInvocation.java:182)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(
ReflectiveMethodInvocation.java:149)
at org.springframework.transaction.interceptor.Transa ctionInterceptor.in
voke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(
ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopPro xy.invoke(JdkDynami
cAopProxy.java:204)
at $Proxy11.analyse(Unknown Source)
at com.gt.ihm.Application.run(Application.java:736)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.MissingResourceException: Can't find bundle for base name o
rg.jfree.chart.plot.LocalizationBundle, locale en_US
at java.util.ResourceBundle.throwMissingResourceExcep tion(Unknown Source
)
at java.util.ResourceBundle.getBundleImpl(Unknown Source)
at java.util.ResourceBundle.getBundle(Unknown Source)
at org.jfree.chart.util.ResourceBundleWrapper.getBund le(ResourceBundleWr
apper.java:128)
at org.jfree.chart.plot.XYPlot.<clinit>(XYPlot.java:326)
... 16 more

mogwai316
10-05-2009, 05:49 PM
I get a very similar but not exact error as the above message when I try to run it from the command line also. If I just double-click the JAR from Windows, nothing seems to happen.

Ggrognon
10-06-2009, 01:37 AM
Hi. Your tool looks really good. but i miss the option to choose the alias to show all hands if you play at more than one site.


+1

OK, I add this to the TODO list.

Sorry for the late answer, but after after spend a lot of time doing SECT, now I try to play more. New releases will come slower.

Ggrognon
10-06-2009, 01:43 AM
Caused by: java.util.MissingResourceException: Can't find bundle for base name org.jfree.chart.plot.LocalizationBundle, locale en_US


This is the error.
This is the first time I see this error. I'll try to guess what's the cause.
When you have succh a problem, it is better to send error messages by PM.


I get a very similar but not exact error as the above message when I try to run it from the command line also. If I just double-click the JAR from Windows, nothing seems to happen.

When you have an error, messages are sent to the console. When you run SECT from "windows", you have no console. If an error occurs, you just see nothing, SECT just stops working. When you run SECT from the dos console, you can see the error messages.

omaha
10-06-2009, 06:01 PM
EXCELLENT PROGRAM! Hem really stuffs its calculations up, unlike yours!

A couple of little isssus that would make things MUCH easier to read

i) HAve the numbers on the right hand side of the graph as well

ii) on my graph there are about 22 horizontal lines, with numbers ranging from -750 to +4250. The problem is it is really difficult to guess what numbers are in the middle of the graph. If say every fourth line was slightly darker, then it would show every thousand blinds very nicely

iii) If you have another line from 0,0 to the end of the graph, and then have something like 3.5bb/100 hands, so we know what our long term results are

rjpageuk
10-07-2009, 02:40 PM
Has anyone run this and found they have won more than they should have over a significant sample?

HEM has me running just over 1BI down on AIEV over 55k hands at 25NL (the last time I ran ok over any sample) and your software has me down 20BI on expected over the same sample. This seems unlikely, although I havent done anything other than just run the software.

If your software is to be believed I am now down 63BI on expected over my last 150k hands which also seems a bit unbelievable.

It should not be standard for winning players to run under EV, the explanations for this make no logical sense.

omaha
10-07-2009, 11:03 PM
rjpaek, i tend to believe sect rather than hem

Hem ev allin calcs are bullshit, they just look at the %when the last dollars go in

For example, if i have AA and you have 45, and i get 200 in preflop, 500 on the flop, 10 on the turn. If you hit your straight on the turn, i think you get 100% equity on the entire pot, despite the 700 (out of 720!) you got in as a massive dog!

Sect would seem to proportion the 200 pre, the 500 on the flop, and the 10 on the turn and get a much more accurate figure

My guess is that youu have been getting most of your money in bad, but then getting the remainder in well, this would explain being 1bi down at hem but 20bi down on sect

omaha
10-07-2009, 11:05 PM
I have a quick question on how the ev calcs are done when all in

Hypothetically, if there is nothing in the pot, and i put 100 in and it is called, and i am 100% chance of winning, what number is calculated?

Is rake of 5% or whatever taken out of the 200 pot, or not?

Everyones always complaing that they are runnng below ev (particularly hem, pt3 and pokerev) , could it just be that hem and pt3 show us how good we are BEFORE the rake is taken out?

If not, can you please account for the rake at different sites? My feeling is that everyones graphs would be very close to normal if rake was taken into consideration

Flurgorg
10-08-2009, 08:10 PM
This has confirmed how terribly bad I've been running lately :(. But still, very nice program!

fiammaz
10-18-2009, 04:55 AM
I can't try it right now so.... Do you plan to "rebuild" an Pokerev for HM? (including all Pokerev features)

mig5000
10-21-2009, 10:20 AM
does it work for omaha ?

richbrown
10-23-2009, 07:57 AM
I can't seem to open the program after downloading it. using vista x64.

I extracted the files in a folder but now what? There doesn't seem to be a program file and or setup file ect. Sorry for being a tard.

also I DL the java files as well.

xbrianx
10-23-2009, 02:58 PM
18 buy ins below EV in the last 8k hands...somebody turn of the F@(&ing doomswitch!

...but enough about me...

Great program! I really appreciate being able to discern whether I'm on a losing stretch because of bad cards or bad play. Thank you for sharing this with us.

tristanbleu
10-24-2009, 11:15 AM
Hi all,

of course you're all running below "EV" on big sample...

You cannot analyze all hands that went to showdown without taking into all the hands that did not went to showdown. You're heavily skewing the results towards hands where your opponents hit the flop/turn/river.

As I understand it SECT is an example of the logical fallacy named "The Defense Attorney's Fallacy".

It shall show what people want to see: that they're running bad.

And it's not true at all.

The probability that someone trying this software is really running 63 buy-ins behind EV on 150K deals is very low.

The probability that this result is due to the logical fallacy called "The Defense Attorney's fallacy" is very high.

I'd love it if the author could explain my why the results aren't completely skewed... and why this is software is not based on an entirely false premise.

The only mathematically accurate indisputable EV-adjusted corrected result that can be computed can only be computed when complete information is available, and this only happens when there's an all-in before the river.

:D

rjpageuk
10-26-2009, 05:14 AM
The only mathematically accurate indisputable EV-adjusted corrected result that can be computed can only be computed when complete information is available, and this only happens when there's an all-in before the river.

Good post.

The HEM AIEV calculator is rubbish because it only calculates EV on the street that the AI occurs, this software could do a proper street by street calculation but only in cases where an AI eventually occurs.

tristanbleu
10-26-2009, 07:05 AM
The HEM AIEV calculator is rubbish because it only calculates EV on the street that the AI occurs, this software could do a proper street by street calculation but only in cases where an AI eventually occurs.

Ouch no...

Actually that would be completely bogus.

HEM's AIEV calculator is not rubbish, it tries to be correct. It's SECT that is rubbish :)

A player that is all-in before the river is all-in before the river and the only proper calculation is computing his AIEV from the street he's all-in. There's no such thing as a "street by street" EV that can be accurately (or even closely or even very approximately) computed.

The only thing that *could* be computed would be your EV on a deal where you commited yourself at some street and that then went to showdown. But then one would need a *very* precise definition of one commiting oneself means. Any other tentative is delusional and it can be proved to fall under one the many gambler fallacy.

Say you're all-in preflop and two other players are covering and going to showdown, without having any of these two opponents being all-in (but they go to showdown).

You can compute the AIEV for 'pot 0' for both you and the other two players. But there's no "at every street EV". The only momemnt where we have perfect information in such a deal is for pot 0 (the pot you can claim being all-in preflop and being covered by two other players).

There's no "street by street" EV for pot0. There's AIEV for pot0 and it can be accurately computed and it's that value that HM computes (if HM's AIEV algorithm is correct).

What I mean is for you, by being all-in preflop, you don't care what the actual streets cards are. Your AIEV does *not* depend on the flop cards, nor turn card, nor river card. Your AIEV is fixed as soon as you are allin: complete information is available and your AIEV can be computed (as well as the AIEV for that pot for opponents going to showdown).

In addition to that, in that same example, you cannot compute any EV for the the opponents going to showdown without being all-in: their very decision to stay in the deal has been influenced by the actual flop, turn and river cards. SECT fails to understand that and hence compute some ethereal "EV" on deals that went to showdown, failing to realize that in a lot of case people folded because they didn't hit the flop/turn/river.

Geof11061
10-27-2009, 12:11 AM
What I mean is for you, by being all-in preflop, you don't care what the actual streets cards are. Your AIEV does *not* depend on the flop cards, nor turn card, nor river card. Your AIEV is fixed as soon as you are allin: complete information is available and your AIEV can be computed (as well as the AIEV for that pot for opponents going to showdown).


Correct me if I'm wrong, but I don't think this is what this calculator does.
AIEV is taken as the probability of winning the hand at the moment all the money went in, it is not then subsequently calculated on each street.

It is calculated on each street if the players were not all in on the previous street.

Have a look at the example in my post here:

http://www.holdemmanager.net/forum/showthread.php?t=20227

This is the figure I think this is calculating. My example resulted in an actual loss of 100 BB, but the figure produced here would be a gain of 37.45 BB. (All in preflop would produce a gain of 65BB on average).

So the EV figure produced here does not have any bias in it at all - it should always run close to the true amount won over time.

If you look at the author's graph, I would imagine this is fairly typical. It will sometimes be above, sometimes below the true winnings line but should always be close.

You say that SECT fails to take into consideration the fact players do not continue after the flop etc, but on the contrary - it is a measure which takes precisely this into account since after a fold because of an unfavourable flop, no more calculation is done.

nakke
10-29-2009, 08:42 AM
Nice tool, ty! Shipped $5 to you on FTP <s>as a thank you</s> for better karma. :)

tristanbleu
11-01-2009, 08:02 AM
AIEV is taken as the probability of winning the hand at the moment all the money went in, it is not then subsequently calculated on each street.

We completely agree on that one. And such an AIEV is using complete information and represents an mathematically undisputable calculation. It doesn't claim to "solve" the problem where you commit 80% of your stack preflop when you're ahead, then the last 20% at flop when you're behind.

What it does, however, is mathematically correctly determines your AIEV for those last 20%, in that case.





http://www.holdemmanager.net/forum/showthread.php?t=20227


I hear you... This is exactly my point: being able to determine your true equity in such a case needs a very good definition of what being commited means.

In the very unlikely case that one could only approach such a definition, then a tool like SECT could be made to work. But having a definition of being commited is shabby at best.

Say you 3-bet overbet to 30% of your stack a donkey pf with JJ... You're commited right? Then donkey calls, flop comes monochrome AKQ of a suite you don't have and donkey donks all-in. Do you give the 70% of your stack?

How can an algorithm decide if a player is commited or not?


You say that SECT fails to take into consideration the fact players do not continue after the flop etc, but on the contrary - it is a measure which takes precisely this into account since after a fold because of an unfavourable flop, no more calculation is done.

No it is not. That's what the author (silent on the subject) and the users of SECT don't understand. It's plain and simply broken.

You say "no more calculation is done" but it is not true. You're completely screwing the other computations that are done by doing "no more calculation".

Example: you raise AA to 80% of your stack preflop, donkey calls, flop comes K83 rainbow, you go all-in for your last 20%.

Case 1: donkey calls with 87, SECT shows you as running mostly as expected.
Case 2: donkey calls with 33, being a huge favorite, SECT shows you as running bad.

But what about all the cases where villain folds !?

That is what SECT fails to capture. You cannot consider that you got unlucky when the donkey hit 33 yet "not compute anything" all the times where donkey folded.

The cases where donkey folded completely screw the other computations.

Lets simplify our scenario even more:

- you have AA, you raise to 80% of your stack, donkey calls, flop comes K83 rainbow.

- you then go all-in, no matter the flop, because you're committed.

- out of 100 times, 99 times donkey folds.

- 1 time donkeys calls with 33.

What shall SECT bogusly do? It shall do no computations for the 99 times where donkey folded, "no more calculation".

What shall SECT do the one time where donkey calls with 33 ? Shows that donkey sucked out and that you got unlucky.

So altough you ran obviously uber-good by having donkey folding 99 times out of 100 (donkey and his 33 his expected to hit a set of 3 much more often than once in 100 times), SECT only focus on that one time where donkey hit his set and tells that you're running below EV.

It's precisely because SECT does nothing to your adjusted-graph on these case where the opponent folded that it is completely bogus.

This is a well-know gambler fallacy.

I suggest continuing this discussion in a "Poker theory" forum but honestly SECT is based on a broken premise and should not be used.

naru
11-04-2009, 12:25 PM
I'm sceptical and tend to agree with tristan here.

my four graphs (admittedly only 50k hands total) are _all_ below EV, and sometimes significantly so. I mean it would be nice if that were true, but honestly I don't think I've run that bad.

Could someone post a graph where he actually runs above EV according to this tool?

omaha
11-06-2009, 09:55 AM
I personally thing the reason we are all running below ev is because calcs are done NOT including rake. Thus, if the pot is say 200, and we have a 40% chance of winning, then sect assigns us 100 of the pot, where in reality it might be 94, or 97.

THe amount i am running below over a large sample is approximately what i am paying in rake (except for my retarded doom switch last 30k hands)

As for those arguing whether sect or hem is better, i think sect is massively better.

The argument that showdown vs non showdown is irrelevant if you are looking at a graph with BOTH in them, rather one in isolation.

When tristan states that sect fails to consider the cases when villain folds, he doesnt realise that when villain folds his hand, the result of this will show up in the non showdown winnings, which, on his example will be massively skewed in our favour

As for needing to be all in prior to the river to calculate things accurately, what crud. As long as we know the cards, i think it is massively beneficial to calculate things street by street.

Example, get 99bb in with AAvs 22 pf, villain hits his 2 on the river, and we then get ai, hem will give us ZERO % equity.

In poker, all we can try to do is get our money (over four streets) in good. Hem does not show this at all, sect does it very well.

tristanbleu
11-06-2009, 09:14 PM
The argument that showdown vs non showdown is irrelevant if you are looking at a graph with BOTH in them, rather one in isolation.

When tristan states that sect fails to consider the cases when villain folds, he doesnt realise that when villain folds his hand, the result of this will show up in the non showdown winnings, which, on his example will be massively skewed in our favour


I know much more on that subject than you think. I created an account on this forum only to point out the fallacy behind SECT in this newsgroup.

I realize exactly everything I wrote, it's you that don't realize something, and I'll explain it in great details here now.

It is not irrelevant and it wouldn't be 'skewed'. Non-showdown graph is correct and mathematically undisputable. HM has a correct non-showdown graph and a correct all-in EV graph.

So your post starts with a false premise: you say that I "fail to realize the non-showdown line will be skewed in our favor".

But a non-showdown line cannot be skewed. That's was kinda the point of my post.

A non-showdown line is a non-showdown line. The definition of a non-showdown line is well-known, unarguable, and represents exactly how much money you made in non-showdown pots.

Give me as many hands as you want, I'll graph you the non-showdown graph and it ain't going to be 'skewed'. It is going to represent exactly what you made or lost in non-showdowns.

So let's recap:

showdown + non-showdown = your actual result.

AIEV = what your showdown results should have been (by adjusting pre-river all-ins showdown only) + non-showdown.

SECT = what your showdown results should have been by adjusting all deals with known showdown cards + non-showdown.

Realize that all these non-showdown are identical in all these cases and mathematically indisputable. There's no arguing here: I'm stating a fact.

I don't care if villain folded 999999 out of one million. The non-showdown line is still correct. It represents what really happened.

I may have my non-showdown line nearly vertical, great. It's what happened. In all cases: actual results, AIEV results, SECT results... The non-showdown line is the non-showdown line. No skew here. Just facts.

Now the SECT-adjusted showdown is bogus and comes from weed-smoking-faerie-delusional-land and I'll re-explain why. It is skewed for the very reason I explained that you refuse to acknowledge. It is a well-known poker players fallacy.

Once again: you cannot hope to adjust results at showdown on a street-by-street basis for deals that go to showdown because you are skewing these showdowns towards deals where villain hit good cards (which is why villain is still there and appears to be so lucky). The non-showdown aren't and cannot be skewed: they are undisputable. They represent what really happened.

Let's take my example again, with a more detailed explanation of what HM and sect do:

- you have AA, you raise to 80% of your stack, donkey calls, flop comes K83 rainbow.

- you then go all-in, no matter the flop, because you're committed.

- out of 100 times, 99 times donkey folds.

- 1 time donkeys calls with 33.

Real winnings graph: sum of 1 showdown (say that villain won on a K837J board) + 99 non-showdown.

HM AIEV graph: sum of 1 showdown graph where we consider we're behind with AA vs 33 on a K83 flop, which is mathematically correct and which everyone using AIEV knows (even if it doesn't capture what [b]you[/] would like doesn't exactly make an AIEV graph unnecessary).

SECT graph: sum of 1 showdown where we consider we were way ahead with our AA preflop vs 33 but got suckered out on the flop + 99 non-showdown.

Do you really still fail to realize why SECT is utterly and completely bogus and delusional?

In addition to that:

1. it is a well-known gambler fallacy
2. what is the probability that all people in this thread are well below EV? (and it's not a rake thinggy, it's a heluva number of buy-ins below EV for some)?

Seriously? Can't my posts + the fact that several posters have serious doubt about those magical graph where "everybody is running bad" make you change your mind? (I hope it can, because mathematical facts and gamblers fallacies won't change to accomodate your view ; - )



As for needing to be all in prior to the river to calculate things accurately, what crud. As long as we know the cards, i think it is massively beneficial to calculate things street by street.

crud?

You do not know things street-by-street. You know things street-by-street for heavily skewed deals where villain didn't fold.

And why didn't villain fold? Because very often he hit or hit a draw.

Non-showdown is irrelevant: non-showdown is the same in HM and SECT. Non-showdown is correct and we all know how to interpret it.



Example, get 99bb in with AAvs 22 pf, villain hits his 2 on the river, and we then get ai, hem will give us ZERO % equity.


Yes, as will all correctly programmed (that is: not PT ones) AIEV algorithms. It never claimed to solve all the world's troubles. AIEV does what it does and never claimed to be useful in the case you're showing here. Once again, the fact that AIEV in your example isn't useful doesn't make AIEV 'wrong'. AIEV captures all-in luck on pre-river all-ins and does it correctly and in a mathematical undisputable way (it's the only way in Hold'em where you have perfect information).



In poker, all we can try to do is get our money (over four streets) in good. Hem does not show this at all, sect does it very well.

HM shows it to some extend, especially in NL where quite some of the "200 bb pots" deals tend to involve pre-river all-ins (or all these all-ins vs shortstackers). And HM isn't the only one to show this.

SECT doesn't do this very well at all.

SECT is based on a logical fallacy and is completely skewing the results.

I'm done, I've written lenghty posts and have had several people agreeing with my detailed explanation.

I've debunked the very premise of your post: that I "failed to realize that non-showdown would be skewed in our favor". But "non-showdown skew" is a contradiction in terms.

I suggest continuing this post in a "Computer Theory" forum and you'll see that people there shall agree with my view.

I suggest reading the articles at pokersleuth.com :

* The Gambler's Fallacy
* The Prosecutor's Fallacy
* The Defense Attorney's Fallacy
* The Normality Fallacy

Note that I'm not in any way arguing here: I'm stating mathematically indisputable facts. These kind of gambler fallacies have a name for a reason: many people do fail to recognize them.

I happen to be very familiar with these fallacies and very familiar with AIEV algorithms.

What's the probability I'm correct on this subject?

:cool:

wachtwoord
11-11-2009, 03:25 PM
I too registered to respond here and that is to tell you you are wrong at least with respect to one thing.



It is not irrelevant and it wouldn't be 'skewed'. Non-showdown graph is correct and mathematically undisputable. HM has a correct non-showdown graph and a correct all-in EV graph.

So your post starts with a false premise: you say that I "fail to realize the non-showdown line will be skewed in our favor".

But a non-showdown line cannot be skewed. That's was kinda the point of my post.

Non-showdown winnings is skewed. I think you simply define skew differently than others (including me).

The showdown line gives 100% of the equity of the pot to the one not folding. When the hand is being played this is blatantly incorrect since at various streets one of the villains folding has put money in with a pot equity not equal to zero!

To unskew the data we would need to calculate the equity of each villain for each street except the street at which that specific villain folds.

So, say I raise pf and villain has 30% equity and calls. We are heads up to the flop and the pot is $10, then villain is entitled to $3! Then he donk-bets, I raise and he folds. All the winnings on the flop are 100% mine, since villain folded.

This addition is necessary to reward chasers with the right amount of equity. If villain chases a FD to the river, and check/folds the river, he is entitled to some of the equity because if he had hit his flush (of which he had a certain chance of making when he put his money in the pot) he would have won the pot.

Sadly we can never calculate this witout the explicit help of poker sites since we would need the hole cards to be revealed.



What's the probability I'm correct on this subject?
:cool:

With this argumentation? 0% as I debunked your premise :)

[sorry for that last one but I really hate Argumentae ad auctoritatem ...... (is ae the plural? lol)]

Recon20k
11-20-2009, 10:19 AM
hey mate does this street-by-street ev calculator work for omaha ??

structure
11-21-2009, 06:12 PM
Any chance we can get one of these for omaha??

Logun
11-22-2009, 12:33 AM
I like it but I see 2 list entries for .1/.25NL
which is of course my current limit.

regardless of which one I select it shows me 7 hands rather than the 250K I have played.

All other limits I have tested work fine (all, .05/0.1nl and 0.25/0.50nl)

running current version 3.2.7

naru
11-22-2009, 04:26 PM
guys,

it has been demonstrated that the results of this program aren't correct.

you might as well just draw your own runbad graph to make you feel better :-)

Logun
11-22-2009, 04:28 PM
I thought it was only incorrect when adding in non-SD hands?

Geof11061
11-24-2009, 11:11 AM
guys,

it has been demonstrated that the results of this program aren't correct.

you might as well just draw your own runbad graph to make you feel better :-)

No it hasn't - somebody has put forward a theory on why thy think it is incorrect, others have said why they think it is correct.

Those that have said they think it is incorrect have quoted a number of mathematical fallacies which have absolutely no relevance to this situation whatsoever.

teecee90
11-24-2009, 04:04 PM
A doctor friend of mine was once taking over-the-counter drugs which he knew to have no clinical benefit for his condition. When I asked him why he was taking it he replied "because it makes me feel better".

Wietse
11-29-2009, 10:39 PM
Although we still dont know if your tool really gives you an idea of your true expected winrate I do like the work you have put in it and think you should be rewarded for this. Thx!!
edit: I just read OP again. Is this tool making the exact same calculations as Poker EV did? In other words are these sklanskybucks?

I am gonna send you some $ when I get my 4k bonus at stars. Unless I have gone broke before that ofcourse.

What do you guys make of this?

Wietse
11-30-2009, 03:57 AM
I'm sceptical and tend to agree with tristan here.

my four graphs (admittedly only 50k hands total) are _all_ below EV, and sometimes significantly so. I mean it would be nice if that were true, but honestly I don't think I've run that bad.

Could someone post a graph where he actually runs above EV according to this tool?

The weird thing is HEM showing an actual win for $600ish and sect shows a $1000ish.

The first 65kish hands are from 50NL the last 15K+ are 100nl

Wietse
11-30-2009, 03:59 AM
hmm cant seem to attach the 2nd screenshot in 1 post

fasteddie_21
12-04-2009, 03:19 PM
Ok, I tried reading tristanbleu's posts, but I'm still confused.


Maybe if you guys could clear this situation up for me and explain it to me (like I'm 5 :) ) maybe I can understand this better, please.


Say you are playing 100nl. You raise to $99.99 preflop w/ AA and get called by KK. The flop is Kxx and he bets the final $0.01 and you call.

As it is now, the HEM EV calculator would show that you got all $100 in horribly bad, since you weren't all in, but still had that $0.01 as a 4:1 fav.

That can't be correct, right? I'm trying to wrap my head around this and am failing. So please, if someone can clear this up, I'd be greatly appreciative.

wachtwoord
12-04-2009, 09:00 PM
SECT is more correct than HEM AI. But it still has some flaws due to the imperfect information in the game (read: non showdown pots).

Peewee
12-10-2009, 01:29 PM
So I'm guessing this means im running bad at the minute!! :mad:

JPFisher55
12-10-2009, 03:11 PM
SECT is more correct than HEM AI. But it still has some flaws due to the imperfect information in the game (read: non showdown pots).

I agree, but SECT also has a flaw that if you have a good hand, like a set, opponent hits a straight on turn, then you get all your money in and lose, your bad luck has cost you more money than SECT will calculate, but more than an all in EV calculation.

Knowing your odds of winning for each street for all showdown hands and being able to compare how it changes for each street would tell you more about your luck, or lack thereof. But these stats must be difficult to calculate or derive because HEM does not provide them and PT3 does not have them despite the developer of PT3 advertising them when the product was released almost 2 years ago. The develop of PT3 claim that PT3 will eventually provide these stats, but their claim is over 1 year old.

mak
12-13-2009, 09:11 AM
What's the probability I'm correct on this subject?


Very high. The results of SECT are definitely skewed, as it incorporates the fallacy that you mentioned.

I do, however, have a question about how HEM calculates AI equity. Suppose I have AA and my opponent has AK. We both have $100. We get $99 of our $100 in preflop. The flop comes KKK. My opponent bets his last $1 and I call. I have 0% equity. So, does HEM say that my EV for the "all in" was -$1? Or, does it say my EV on the "all in" was -$100?

If I'm thinking about this right, HEM equity calculation should only concern itself with the money that went in on the flop, and take no consideration from the money that went in preflop. In other words, it should say my EV was -$1.

KrischanXXL
12-13-2009, 12:51 PM
You raise to $99.99 preflop w/ AA and get called by KK. The flop is Kxx and he bets the final $0.01 and you call.

As it is now, the HEM EV calculator would show that you got all $100 in horribly bad, since you weren't all in, but still had that $0.01 as a 4:1 fav.

This is a good example where AIEV fails (like tristanbleu does i my opinion) but SECT works!

HEM AIEV: ca. -$80
(you put $100 in the pot and you have 10% EV on the FLOP in a $200 Pot -> -$100 +10%*$200 = -$80)

SECT: ca. +$60
(you put $100 in the pot and you have 80% EV PREFLOP in a $200 Pot -> -$100 +80%*$200 = +$60)

In this example the SECT method shows nearly the same value as the AIEV would do if both players went all in preflop, which makes sense, since 99.99% went in preflop.

The SECT method of calculation works in both directions, too: When one player in a two-way-pot had a SECT EV of +60$, the other one had a SECT EV of -$60 an vice versa. So this method of calculation can't favor one player over the other and therefore it can't be the reason why you are running under SECT EV (since the other player would run over SECT EV in that case).

But Rake should definitely be taken into account, i think! This can cause greater errors than one might think.

Let HEM show you the rake paid in your showdown pots only and try to deduct that value from the SECT EV. Should work in my opinion... Haven't really elaborated this though.

mak
12-13-2009, 07:58 PM
This is a good example where AIEV fails (like tristanbleu does i my opinion) but SECT works!

HEM AIEV: ca. -$80
(you put $100 in the pot and you have 10% EV on the FLOP in a $200 Pot -> -$100 +10%*$200 = -$80)

SECT: ca. +$60
(you put $100 in the pot and you have 80% EV PREFLOP in a $200 Pot -> -$100 +80%*$200 = +$60)

In this example the SECT method shows nearly the same value as the AIEV would do if both players went all in preflop, which makes sense, since 99.99% went in preflop.

The SECT method of calculation works in both directions, too: When one player in a two-way-pot had a SECT EV of +60$, the other one had a SECT EV of -$60 an vice versa. So this method of calculation can't favor one player over the other and therefore it can't be the reason why you are running under SECT EV (since the other player would run over SECT EV in that case).

But Rake should definitely be taken into account, i think! This can cause greater errors than one might think.

Let HEM show you the rake paid in your showdown pots only and try to deduct that value from the SECT EV. Should work in my opinion... Haven't really elaborated this though.

Why doesn't HEM AIEV look at only the money put in on the street of the all in (and ignore money put in on previous streets)? Seems like it would be more accurate to do it that way.

entropy01
12-25-2009, 08:23 AM
Why doesn't HEM AIEV look at only the money put in on the street of the all in (and ignore money put in on previous streets)? Seems like it would be more accurate to do it that way.

I edited .xml file...downloaded current .rar file, got program to launch...but when I enter in my name it gives an error message stating the user is unknown. Any idea what I am doing wrong?

CivSTAR
12-28-2009, 07:07 AM
can it be, that SECT doesn't work correctly with €? would be cool if you could fix that :)

omaha
01-20-2010, 06:59 AM
If the rake is not taken into account, then this can explain why everyone is running below ev (aside from the fact that people who are running above ev arnt looking at this sort of stuff)

For example, we get aipf with 100$ with AA vs AA, an obvious 50% equity scenario, and both hem and sect will show us winning nothing, ie having an ev of zero.

REal world scenario, enter the RAKE, we do not get our 100 back, we get say 97$. Thus, our winnings (of minus three dollars ) is just a little bit below our ev of zero.

Does anyone realise just how hard the rake is to beat?

At party, its about

9.1 bb/100 hands at NL100
6.5 bb/100 hands at NL 200
4 bb/100 hands at NL400
3.0 bb/100 hands at NL 600


ie per 10000 hands,

NL 100 you will be down about 910 blinds
NL 200 you will be down about 650 binds
NL 400 you will be down about 400 blinds
NL 600 you will be down about 300 blinds

And in decent 50k hand samples
NL100 down 4500 blinds
NL200 down 3200blinds
NL400 down 2000 blinds
NL600 down 3000 blinds


Now, being down a few thousand blinds over a 50k hand sample looks really bad, but is it really?

Almost all of the running bad graphs i see on sect, hem or pt3 or whatever would look a whole lot better if people realised that the all in graphs WILL ALWAYS LOOK HIGHER THAN OUR BANKROLLS BECAUSE THEY DO NOT CONSIDER RAKE!

Now, we shouldnt be running as low as the numbers above suggest, as it is only the all in calcs that do not have rake included (correct me if im wrong)


What i would really like is for hem , pt 3 and sect to at least have an option where rake is considered, and removed from your all in ev line. After all, if its not in our account, why should we see it in our line?

nakke
01-20-2010, 09:55 AM
They do consider rake. Or is according to you the average NL100 50k hand graph 45 buyins under EV?

Mon
01-20-2010, 11:46 AM
They do consider rake. Or is according to you the average NL100 50k hand graph 45 buyins under EV?

Agree, I've done the maths and indeed HM takes into account rake removed from pot.

dye_
01-21-2010, 07:57 PM
What Postgres Version do you need?

I have 8.3 and it doesn't work.
He can connect to PostgresSQL Server and also recognizes if i type a player in that doesn't exist, but if i want to him to analyse anyone he says 0 Hands to parse...

Spurious
01-24-2010, 10:55 AM
Can you do this for Omaha please one time !

new_draks
01-31-2010, 02:13 PM
it doesnt work for me :/

new_draks
02-03-2010, 04:58 PM
it doesnt work for me :/

what can i do? i go step for step and nothing

Hratch
02-12-2010, 12:30 AM
Example: you raise AA to 80% of your stack preflop, donkey calls, flop comes K83 rainbow, you go all-in for your last 20%.

Case 1: donkey calls with 87, SECT shows you as running mostly as expected.
Case 2: donkey calls with 33, being a huge favorite, SECT shows you as running bad.

But what about all the cases where villain folds !?

That is what SECT fails to capture. You cannot consider that you got unlucky when the donkey hit 33 yet "not compute anything" all the times where donkey folded.

The cases where donkey folded completely screw the other computations.

Lets simplify our scenario even more:

- you have AA, you raise to 80% of your stack, donkey calls, flop comes K83 rainbow.

- you then go all-in, no matter the flop, because you're committed.

- out of 100 times, 99 times donkey folds.

- 1 time donkeys calls with 33.

What shall SECT bogusly do? It shall do no computations for the 99 times where donkey folded, "no more calculation".

What shall SECT do the one time where donkey calls with 33 ? Shows that donkey sucked out and that you got unlucky.

So altough you ran obviously uber-good by having donkey folding 99 times out of 100 (donkey and his 33 his expected to hit a set of 3 much more often than once in 100 times), SECT only focus on that one time where donkey hit his set and tells that you're running below EV.

It's precisely because SECT does nothing to your adjusted-graph on these case where the opponent folded that it is completely bogus.


Your problem is that you are attempting to hold street-by-street EV to a higher standard than allin EV: No one claims that street-by-street EV factors out luck completely. Our claim is that it factors out luck more than allin-EV does. So stop talking about the donkey not hitting a set enough. etc. We know that that luck factor (how often you hit a set) is not accounted for by street-by-street EV, but remember that it is also not accounted for by allin-EV. So we're even there.

However.

In cases where the hand goes to showdown, street-by-street EV presents a weighted expected value of how good you put your money in the pot, which is a better measure than just looking at your equity when you put your last dollar in. We are comparing street-by-street to all-in EV, and we believe it is a better measure for factoring out luck. Nobody is claiming that it completely eliminates luck. Please.

Roy, we want street-by-street EV!!!

Hit_or_Miss
02-14-2010, 04:18 AM
asides: If you don´t get why this is more accurate than All In EV you have no clue about what poker is all about.

SEcT is very cool, thank you. However it does not work with RUSH hands, it just does not import any hands.

Am I doing wrong, will this be "fixed".

best regards

rjpageuk
02-14-2010, 02:01 PM
Your problem is that you are attempting to hold street-by-street EV to a higher standard than allin EV: No one claims that street-by-street EV factors out luck completely. Our claim is that it factors out luck more than allin-EV does.

I dont think it does, can anyone who is reading this thread say that SECT shows them running anything other than horribly bad over a decent sample?

According to SECT I am down now nearly 80BI over my past 200k hands, with my "running bad" at an almost consistent 4bb/100 hands now.

I originally bought into the idea of this program but tristanbleu is correct: only factoring in the cases where you see showdown only accounts for the times you get sucked out on (as villian never folds), which skews the results far more than the multitude of problems HEM AIEV has. This explains why my running bad has been so consistent and so high: it just isnt true.

There is an insane amount of luck in poker and there is no way to properly calculate it because it is all dependent on villians range for specific actions (and so you could keep running in to the top / bottom of it and there is no way to properly tell). Over a decent sample with hole cards always visible to the software a street by street EV analysis would work but it is not possible.

Run the program and see how much you are running bad if it will make you feel better but dont pretend that it explains the actual situation.

JPFisher55
02-14-2010, 07:20 PM
I dont think it does, can anyone who is reading this thread say that SECT shows them running anything other than horribly bad over a decent sample?

According to SECT I am down now nearly 80BI over my past 200k hands, with my "running bad" at an almost consistent 4bb/100 hands now.

I originally bought into the idea of this program but tristanbleu is correct: only factoring in the cases where you see showdown only accounts for the times you get sucked out on (as villian never folds), which skews the results far more than the multitude of problems HEM AIEV has. This explains why my running bad has been so consistent and so high: it just isnt true.

There is an insane amount of luck in poker and there is no way to properly calculate it because it is all dependent on villians range for specific actions (and so you could keep running in to the top / bottom of it and there is no way to properly tell). Over a decent sample with hole cards always visible to the software a street by street EV analysis would work but it is not possible.

Run the program and see how much you are running bad if it will make you feel better but dont pretend that it explains the actual situation.

I agree that SECT does not totally represent you luck. If you get out flopped or out drawn on the turn, SECT will underestimate your bad luck. OTOH, it cannot account for hands holding up that were not showdown. All in all, because it represents a higher sample than all in EV stats, IMO it has more value than all in EV. However, it is more like a supplement to all in EV than a replacement. Street by Street win percentages would be the best measure of luck, but not determinative by itself.

Hit_or_Miss
02-15-2010, 02:00 AM
It is not working for RUSH.

Help please

Hit_or_Miss
02-15-2010, 03:13 AM
only factoring in the cases where you see showdown only accounts for the times you get sucked out on (as villian never folds)


wrong, that shows how much you do not understand. it also factors all hands where you hold up, in which case you get more chips than you "deserved".

I have months where I am running way above expectation, and months where I am way below. A month means 80k+ hands in my case.

What is not covered is all the other ways of variance (cards dealt, cold decks, setups), but there is no other graph that is able to cover that.

Lets look at that scenario: Someone forces you to use all of your bankroll to back another player. You can choose one of 9 players who already played 100 hours online together. You have not seen them play. You can choose only one of the following informations:


1.) Their real results corrected by AIEV according to HEM
2.) Their real results corrected by SEcT (aka their Sklansky bucks)

Now which data will you choose?

DK115
02-15-2010, 09:47 AM
I do, however, have a question about how HEM calculates AI equity. Suppose I have AA and my opponent has AK. We both have $100. We get $99 of our $100 in preflop. The flop comes KKK. My opponent bets his last $1 and I call. I have 0% equity. So, does HEM say that my EV for the "all in" was -$1? Or, does it say my EV on the "all in" was -$100?

If I'm thinking about this right, HEM equity calculation should only concern itself with the money that went in on the flop, and take no consideration from the money that went in preflop. In other words, it should say my EV was -$1.

Yes!

The problem here is you try to relate your decision at the flop at something you only know after the flop. This can only be done if you know all about decisions pre-flop and that you do not know because there are a lot nonshowdowns ... What if this has happened 10000 times and in 9999 times this AK-guy has folded ... still no good calculation?

Tristan is very right ... it looks like a lot of people here are drowning in a river with an average depth of 1 meter ... statistics is not for the average :)

Tristan to bad you do not react here anymore ...

Alexdb
02-17-2010, 04:18 AM
Its true that HEM all-in EV provides an incomplete picture of how your money compares to the the EV of your stratgey.

However, to that extent that it does provide an indication of how lucky you have been, it is correct and unbiased. If you have run badly in all-in EV, then on average you can expect to have run averagely in all other measures of luck and can consider yourself unlucky to they extent that you can measure it.

The measure that this tool provides is incorrect due to a showdown bias (as posters ITT have explained, but others have said they are wrong - they aren't); so it doesn't provide any useful information. That's why HEM doesn't include it, and that's why everyone here is running under EV.

[If you still don't believe this then test it with a 500 hand sample in which you bet pot with the nuts on the turn and villain calls with a flush draw, you bet your last 1c on the river AI. Have villain fold (and not show) 400 times and call 100, and then realise that when you calculate SECT EV the villain has hit the flush 100% of the time for a huge loss of EV.]

Alexdb
02-17-2010, 04:22 AM
wrong, that shows how much you do not understand. it also factors all hands where you hold up, in which case you get more chips than you "deserved".

I have months where I am running way above expectation, and months where I am way below. A month means 80k+ hands in my case.

What is not covered is all the other ways of variance (cards dealt, cold decks, setups), but there is no other graph that is able to cover that.

Lets look at that scenario: Someone forces you to use all of your bankroll to back another player. You can choose one of 9 players who already played 100 hours online together. You have not seen them play. You can choose only one of the following informations:


1.) Their real results corrected by AIEV according to HEM
2.) Their real results corrected by SEcT (aka their Sklansky bucks)

Now which data will you choose?


This is wrong, see my post above. I choose 1), because its a true unbiased estimate of their winrate. SECT <> Sklansky bucks because the sample of hands is taken from those villain chooses to showdown after seeing the last card before betting was completed, rather than the entire distribution.

Adrian
03-01-2010, 11:56 AM
I've just installed this software, and it appears to run fine, but I always get a blank graph with no lines on it. What would be the likely causes of this please?

Adrian
03-01-2010, 12:02 PM
According to Heiko's comments here:

[URL="http://www.deucescracked.com/forums/23-Software-and-Tools/topics/31364-SECT-showdown-equity-calc"]

He believes the SECT software is no good and misleads. What are people's thoughts on this? With so many people finding the software telling them they are runnign really badly, that would fit in with Heiko's comments about how it can mislead.

JPFisher55
03-01-2010, 12:24 PM
I have run badly according to SECT, but I have run it on several competitors who have run good according to SECT. It will understate your bad luck because more money is generally put into the pot on the turn and river. So if you get unlucky on the turn, SECT cannot include the effect of that bad luck because under Sklansky bucks you are putting money in on the turn when you are behind.

It is true that SECT cannot include non-showdown hands. For some players, those hands will tend to be hands for which their flop advantage held up. But for those players who can fold TP to a scary board, then non-showdown hands will include many when their flop advantage did not hold up.

Knowing your percent to win on each street would be very valuable and I hope that HEM soon includes these stats.

SECT does not replace AIEV, it supplements it.

pzhon
03-02-2010, 08:14 AM
It is possible to change from a winning player to a losing player by trying to improve this biased estimate. Don't use it.

Let's suppose you flop a combo draw, a lot of money goes in, and you miss your big draw but river a pair which gives you a bluff-catcher. Your opponent bets all-in giving you 3:1 odds, but you think the odds are 4:1 against your hand being good. It's right to fold. Calling will lose money. Everyone agree?

No, not this estimate. This estimate of your performance will increase if you make this losing call, since it will only see how unlucky you were to miss your draw if you go to showdown, not if you fold. It will reward some playing styles over others. It will tell you to make bad calls so that you go to showdown after missing a draw. It will tell you to fail to make profitable bluffs so that you go to showdown after missing a draw. It will tell you to avoid going to showdown after you get lucky, perhaps by making overly thin value bets, or by folding when you have a correct call. These are symptoms of the fact that this estimate is biased and misleading. It will pat you on the back for playing badly, not for making plays which win money.

I realize there is a lot of confusion about this. It's subtle. You can go through the logic I've given, or just trust me because I have a Ph. D. in mathematics and am a coach for StoxPoker.

JPFisher55
03-02-2010, 12:19 PM
SECT does not purport to reflect your skill, only your luck. All SECT tells you is your Skalansky bucks, expected winnings, for the money that was in the pot preflop, on the flop and on the turn. Then, it compares your expected winnings to your actual winnings. It is not a perfect measure of luck, but such measure does not exist. SECT can't tell you anything about the skill of your play.

pzhon
03-02-2010, 02:56 PM
SECT does not purport to reflect your skill, only your luck. All SECT tells you is your Skalansky bucks, expected winnings, for the money that was in the pot preflop, on the flop and on the turn. Then, it compares your expected winnings to your actual winnings. It is not a perfect measure of luck, but such measure does not exist. SECT can't tell you anything about the skill of your play.
No. SECT does not tell you your Sklansky bucks. It pretends to tell you your Sklansky bucks, but it doesn't. It doesn't see what your opponent had when you don't go to showdown. Measuring Sklansky bucks only in pots which went to showdown is horribly wrong, and can report that you were unlucky when you were actually lucky according to the Sklansky dollars.

Ignore the rake for the moment, since the rake can cloud what skill means, and it's not the point of this discussion.

Average Outcome = Average Net Luck + Average Net Skill.

We know the outcome. If we have an unbiased estimate of luck, then we have an unbiased estimate of skill.

The all-in luck adjustment is an unbiased estimate (except for the bunching effect, which is assumed to be negligible). It's not perfect, and but particularly for SNG players, it accounts for more than half of the variance. For super turbo players, the all-in luck can be 73% of the variance, which means that an adjusted 270 tournaments is about as reliable as an unadjusted 1000 tournaments. For regular SNGs, or for cash game players, particularly microstakes players who rarely get all-in for a full buy-in preflop or on the flop, the all-in luck measures less of the luck, but that it fails to measure some of the luck does not mean it is an unbiased estimator. The all-in luck-adjusted results are still converging to the right value, and they converge faster than the unadjusted results.

SECT is biased. Worse than just being biased, apparently it's biased in a way that many people don't understand, even though I've described above how SECT can favor losing plays and losing styles. This is a way for losing players to fool themselves into thinking that they were just unlucky even though they are being outplayed. This is a program people will keep using precisely when it is lying to them, encouraging them to play badly, telling them that they were just unlucky because they are using a style it likes.

In the long run, all-in luck averages to 0. In the long run, the luck reported by the biased SECT method does not have to average to 0.

JPFisher55
03-02-2010, 03:11 PM
Yes, I know that SECT cannot take non-showdown hands into account. True, you will not know when your advantage hand held up in non-showdown hands. OTOH, unless you always call down on the river with TP, TPTK 2 pair or even a set no matter what the board texture is, then you will also fold hands in which you were outdrawn. SECT is not perfect, but it is a useful tool in evaluating your luck.

The problem with AIEV is that the sample of hands for one player is too small. For the last year, I have run below my AIEV at AP. To check the site's legitimacy, I ran HEM AIEV for other players with hand totals between the several of them about mine. Sure enough they ran above their AIEV. I was jealous. When I added all of our AIEV hands together, the AIEV just about equaled the actual AI winnings. I agree that if you have a mult-million hand database, then AIEV is the best measure of luck. But if your hand database is in the hundreds of thousands, then SECT can help supplement it.

I agree that your SECT results do not alone measure your luck. You need to use it, your AIEV results and other stats. Percent to win for all streets would be another nice stat to have to help evaluate both luck and skill. I hope that HEM adds these stats in the future.

pzhon
03-03-2010, 07:59 AM
Yes, I know that SECT cannot take non-showdown hands into account.
This introduces a huge bias in the examples I gave.

SECT will declare players with some playing styles to be lucky regardless of whether the player gets lucky or not. Other playing styles commonly used by serious players will be declared unlucky even if the player ran well above expectation, and should have lost even more money.


OTOH, unless you always call down on the river with TP, TPTK 2 pair or even a set no matter what the board texture is, then you will also fold hands in which you were outdrawn.

Different playing styles will have radically different rates of going to showdown with various types of hands. So, the errors in the SECT method do not cancel out.


SECT is not perfect, but it is a useful tool in evaluating your luck.

Please enlighten me as to a use other than to fool yourself into thinking that you are getting outrageously unlucky when you are not. The people raving about how wonderful SECT is do not understand that it is biased. It is returning the wrong answer. How is misleading people useful?

Suppose I make a program called "Optimal NL Solver" which returns a play in any situation. People say, "That's just what I need! I want to know the optimum play." But, my program always says "Fold." Sometimes it's right. Often it's horribly wrong. On average, it recommends playing with an overly tight style which loses money rapidly. Is my "Optimal NL Solver" useful? It would be if it lived up to people's expectations, but since it does not, it is useless.


The problem with AIEV is that the sample of hands for one player is too small. For the last year, I have run below my AIEV at AP.

So what? This means nothing. If you flip 100k coins, you are very likely to come up with more heads than tails, or more tails than heads. This does not mean you need millions of coins for them to be fair.

If it confuses you, feel free to ignore AIEV. It's useful to some players, particularly tournament players, high stakes NLHE players, and PLO players who often get all-in preflop or on the flop. It says little for players in nitty games where people don't want to get all-in for 100 bb with JJ, but what little it says is unbiased, so it might mean that it only takes 85k hands to get the reliability of 100k unadjusted hands.


I agree that your SECT results do not alone measure your luck. You need to use it, your AIEV results and other stats. Percent to win for all streets would be another nice stat to have to help evaluate both luck and skill. I hope that HEM adds these stats in the future.
If you want an estimate which converges to the right answer, and you have the SECT information and what HEM now reports, the right thing to do is to drop the SECT information on the floor. Ignore it completely. It's not what people want it to be.

More people might think SECT does what it promises than realize that it doesn't. However, mathematics is not a democracy.

This should not be implemented in HEM.

JPFisher55
03-03-2010, 06:49 PM
Fine how about just adding your chance to win by street for preflop, flop and turn for all showdown hands like it has for all in hands and leave out the actual expected value?

pzhon
03-03-2010, 08:47 PM
Fine how about just adding your chance to win by street for preflop, flop and turn for all showdown hands like it has for all in hands and leave out the actual expected value?
It might be useful to be able to filter by such values, in case you want to review how your opponents play when they flop sets, for example.

The value averaged over the times you went to showdown doesn't have a clear meaning.

JPFisher55
03-03-2010, 10:08 PM
It might be useful to be able to filter by such values, in case you want to review how your opponents play when they flop sets, for example.

The value averaged over the times you went to showdown doesn't have a clear meaning.

If you knew that you were 55% to win preflop on average and you only win 50% then you would know that your luck left something to be desired for those showdown hands. True, those may overweight the hands in which you were unlucky, but it is better than not knowing. Also, I would like to compare my win% on the flop to my win% on the turn to see how much it goes up.

I agree that this knowledge is not a perfect indicator of strategy or luck, but I disagree that it is better not to know at all.

pzhon
03-03-2010, 10:29 PM
If you knew that you were 55% to win preflop on average
First, you wouldn't know that you were 55% preflop on average. You know that the conditional average would be 55% over the hands which went to showdown.


and you only win 50% then you would know that your luck left something to be desired for those showdown hands.
Second, you wouldn't know that. Poker is not about starting with the best hand, or having over 50% hot-and-cold equity. That's a common exploitable conceptual error. See my video on StoxPoker, "Poker Goals and Nongoals" #1256.


I would like to compare my win% on the flop to my win% on the turn to see how much it goes up.

You would not get your win% on the flop or your win% on the turn, since you don't know what happens on the hands which don't go to showdown. This is not a small error. It does not cancel. It is HUGE. Work through the examples I gave before.

It really sounds like you want to build another biased statistic which will tell you the wrong answer. It will not tell you whether you are getting lucky or not. It will reward some playing styles over others. It will tell you that you were just unlucky while you are actually lucky, and are playing losing poker. Is that really better than nothing?

You do not have the information about the hands which didn't go to showdown. You want to measure Sklansky dollars? Fine, that's one consistent accounting system. The Sklansky dollars you win or lose on the hands which don't go to showdown are absolutely critical, and they will be ignored, causing you to misevaluate playing styles systematically.

I'm done. Good luck.

rextyrann
03-06-2010, 08:50 AM
as far as i have understood the conclusion is following:

AI EV is "almost" always correct but very very limited, like only useful for sng/mtt players,

Street EV does cover more ground i.e. all showdown hands but in the long run will be misleading since its ignoring the nsd hands which should be taken into account.

Sklansky Bucks does both so it should be better than either one...

i do not know how skansky bucks work but what i have read from the contra-sect post they seem all to agree that sklansky bucks would do a better job.
in that regard id suggest we vote for that to be implemented in hm since street EV is probably denied as the final conclusion by hm-support!

so guys i do want something better then AI EV. if you do too vote for sklansky bucks!
Graphing Sklansky bucks (http://holdemmanager.uservoice.com/forums/5307-holdem-manger-suggestions/suggestions/132960-graphing-sklansky-bucks)

JPFisher55
03-06-2010, 01:04 PM
SECT calculates your Skansky bucks for all showdown hands. This is incomplete because it cannot include your non-showdown hands. It may be biased for some players. So it is not perfect. IMO, though it is useful. IMO, percent to win for each street for all showdown hands would be useful, but have the same incomplete and potential bias.

However, AIEV includes so few hands that it cannot tell whether you are lucky or not. No stat can perfectly tell whether you are running lucky or not. It will always be a guess. However, IMO SECT and percent to win stats for all streets for all showdown hands would help tell whether you are running lucky or not.

Alexdb
03-28-2010, 01:51 AM
Having scanned over the thread again, I've become in favour of adding SECT to hold'em manager.

The people that understand the game already can ignore it completely, and it's awesome misinformation for villains that don't know that it's misinformation ;)

omaha
04-11-2010, 08:59 PM
HHad to reinstall windows, and sect doesnt want to work for me:mad:

I have downloaded sect 3.2.7, win rar, and have java se dev kit 6 update 18, java 6 update 17 and 18 listed in 'add or remove programs'

When i double click on the sect, nothing happens.

When i try to dos it, i get a 'unrecognisezed opion - jarsectv3.2, could not create the java virtual machine

Any ideas what i am doing wrong?

dare_v
04-20-2010, 06:52 AM
Compliments to the author, great tool!

alejogambler
06-16-2010, 09:58 PM
Hello

When i click the .jar file nothing happens

I already have edited the xml file and installed the last java version... what should i do pls

PS. Win Vista on my computer

scoobediah
08-07-2010, 12:22 PM
Hello

When i click the .jar file nothing happens

I already have edited the xml file and installed the last java version... what should i do pls

PS. Win Vista on my computer

you probably need to change some settings in the xml file. I think the database name is case sensitive.

scoobediah
08-07-2010, 12:32 PM
Is this really accurate? How can these lines be so far apart after 800k+ hands?

Patvs
08-07-2010, 10:13 PM
It's probably because of your playing style.
If you would be over-aggressive (constantly check-raising allin with DRAWING hands as a semi-bluff)---> the EV vs $Won line would be a lot more swingy and the lines closer together.

dare_v
08-09-2010, 10:30 AM
My lines are also very much apart, and I dont have an over aggressive style. I am a fairly TAG players.

Is it possible, that SECT is not that accurate and indeed everybody's lines will eventually be apart, when EV line will be above real $ line or we just a very big sample for it? like a few million hands?

scoobediah
08-09-2010, 10:32 AM
It's probably because of your playing style.
If you would be over-aggressive (constantly check-raising allin with DRAWING hands as a semi-bluff)---> the EV vs $Won line would be a lot more swingy and the lines closer together.

I don't understand why this is. Can you explain why?

dare_v
08-09-2010, 12:34 PM
I think I understand now...

patsv, if our EV line is much above actual line, this means that we play our "draws" too pasivly and if we would go to SD with them, we would win money, correct?

payday
08-10-2010, 08:50 PM
Great tool, I love it.

http://poker1.cwsurf.de/1.jpghttp://poker1.cwsurf.de/2.jpghttp://poker1.cwsurf.de/3.jpghttp://poker1.cwsurf.de/4.jpghttp://poker1.cwsurf.de/5.jpghttp://poker1.cwsurf.de/6.jpghttp://poker1.cwsurf.de/7.jpghttp://poker1.cwsurf.de/8.jpghttp://poker1.cwsurf.de/9.jpghttp://poker1.cwsurf.de/10.jpg

GreedyGenius
08-28-2010, 06:09 PM
Wow. People are actually using it?

Good tool. It keeps bad players think they are unlucky and keep them playing :)

tomits
09-08-2010, 03:14 AM
Currently SECT doesn't read RUSH Poker HH:s.<br />
<br />
Could you add theses? Should be easy, just different limit at dropdown.

mats.b.nygren@telia.com
09-10-2010, 03:28 AM
Made an error :)

stackpointer
09-23-2010, 08:12 AM
hi,i have a question for u.
i play in a super fishy room and i used this tool to calculate my luck/unluck.
this sw is great but i have a trouble:in this room if i win on the river without push my stack sometimes i win pot but villain muked his cards.
for example:if villain bets and i call river and win i see his cards.
if i bet river and villain call and hero wins ,hero doesn't know villain's cards.
this is a fishy room with strange/terrible software so i see a lot of corrupted SDs (i think this is the explanation of this).
Is it still a believable result ?how can i round up/down my expected SD winnings?

capt303
03-25-2011, 05:26 PM
ça devrait fonctionner SECT sur windows seven 64 bits ?
parce que chez moi nada...

superkot
05-10-2011, 01:44 PM
how to run a program ?i download sect.jar /also update java script 6. but how to run a programm ?double click do nothing

progros
05-18-2011, 11:52 PM
work-whether this program for Omaha?

NachoAce
06-19-2012, 02:31 PM
Sect is not working in HM2, correct?

abmalhot
01-20-2013, 10:38 PM
Yes, I dont think so because it gives some weird exceptions when you try to run with HM2..
It says relation "pokersites" doesnot exist.

OP, do you know of any plans if there will be a version of SECT that works with HM2?