If I could put in my own Ranges instead of % and your Handrankings that would be awesome. It`s the one thing that I totally hate with SNG-Wizard.

Thanks for the feedback! Yes indeed, I've got some stuff in the works that should make managing batches of hands much, much easier. Stay tuned!



Depending on which version of Holdemresources and what the settings on SnG Solver are, the reasons could be any of: different equity models, different range restrictions, different range composition, different equilibrium algorithms, etc... In general, the results between programs should be pretty close.



Unrestricted hand ranges will be featured in SnG Sovler v1.1... coming soon!

Been grinding merge being home for a month. Being able to paste merge hh would be nice. But an easy fix that would make things easier would be being able to paste somewhere the total number of chips in play and having the program autoassign the selected player the rest of the chips in play(like wiz does). Just having one less stack size to memorize when inputting would speed things up.

Having customizable ranges would be great. Also having it look ahead a few more rounds and i think youve said thats in the works as well.

Went ahead and bought full version. Easily the best money Ive spent on improving my game in a long time.

Just another bit of feedback for the variable ranges. The fixed ranges make it not usable IMO. I hear the rest of it is amazing and would gladly pay for it but fixed ranges is a major drawback.

That and Merge HHs would be nice.

I should have just quoted Ruse and said "This"

It`s 60/10/10/10/10.

50% of the prizepool = cEV
50% of the prizepool = 20/20/20/20/20
cEV payout = 100% to winner

First place :0.5 x 100 = 50 + 0.5*20 = 60
Secondplace: 0.5x 20 = 10

etc.

If you put these together you get 60/10/10/10/10. So it is the right payout.
--------------

I would like having the option to put in minraises etc.

Thanks for the awesome feedback, guys!


If you guys send me some Merge HHs, I can get them supported

And yup, unrestricted ranges are on the way!


Sounds reasonable... I'll put it on the list for when I make the next pass at the UI.



I'll look into this.


I have something in the works to do this kind of thing... but, shhhhh... its a secret.

NiSash1337's math is correct (thanks for typing it out! ). Though it may not be intuitive, 60/10/10/10/10 gets you the correct answer for the Fifty50s. It sounds like you might be getting hung up because of the label "payouts"... think of it as "payout equity" instead. We're not solving for the actual finish positions for each chip stack, we're solving for the equity.

This is the same reason that when you set the payouts to "winner take all" (just one payout) that $EV become equal to chip EV.

hey

beginners question here

when you are entering the stack sizes of people, do you enter the starting stacks before the blinds/antes are taken or the stacks after the blinds/antes have been taken from each player?

i.e heads up 10/20/2, 1500 chips each at start of the hand
do i put 1500 for sb/btn and 1500 for bb or 1488 for sb/btn and 1478 for bb?

thanks

You enter the size of the stacks *before* any blinds/antes are taken out. So, in your example, you'd be entering 1500 for each stack.

What is the calculation speed difference between calculation using only CPU vs calculation with CUDA graphic card ?

Just to be clear... currently, the publicly available version of SnG Sovler does *not* support CUDA yet (even though you might have noticed that a CUDA DLL is part of the installation). But that said, I can tell you a few things based on some development builds...

On my dev machine with an 2.2Ghz 8-core Xeon CPU and a GTS450 GPU (192 CUDA cores, 1.5Ghz), I see a speed increase of 5-8x when using the GPU.

This seems to be in line with the theoretical performance of each device based on their relative GFLOPS potential (72 vs 576, respectively), but I still believe there is more to be had from further optimizing my CUDA implementation. A real-world GPU/CUDA application has a much better chance of actually approaching maximum theoretical performance than its CPU-based counterpart. So really, I think GPU SnG Solver should ultimately perform better than it would look "on paper" relative to a CPU-only version.

In other words... SnG Solver performance is basically proportional to how many FLOPS you can give it.

For typical modern CPUs: FLOPS = 4 * # physical CPU cores * CPU frequency
For "Fermi" GPUs: FLOPS = 2 * # CUDA cores * GPU frequency
For "Kepler" GPUs: FLOPS = # CUDA cores * GPU frequency

When are you planning to enable this feature ?

Right now, I am not sure. Since my initial CUDA development, I've made some big changes to the SnG Solver engine and to my ideas/goals for the future. Because of this, I've held off on more CUDA work until some of these other things get sorted out.

But I can tell you that GPU/CUDA computing is *definitely* going to be a part of SnG Solver's future. nVidia recently released their new generation of GPUs code named "Kepler" and a new CUDA language spec... and I was very pleased by the direction they're going. The architecture seems to be very well suited to the problem space that I plan to have SnG Solver head into.

Hi Jason,
Great software I really like the PSM model since obviously the traditional ICM calculators have glaring flaws. Two questions regarding Fifty 50s in this respect:
1.Does the Solver calculate the extra EV from action behind Hero if he folds in terms of EqF of Hero stack. Ex:Hero folds on the bubble and two equal stacks get it in and one is eliminated. In this case the value of Hero stack increases enormously in the Fifties since 50% of prize pool is distributed to top 5 finishes.
1.1 If yes does it calculate this extra Equity for the next round as well discounting its EV for the current round.
2.If two equal stacks are on the BTN and UTG does the Solver calculate the difference of their EqF value for just this and the next future round or have you developed an algorithm to account for the extra compound EV the BTN stack has cumulative for each spot until UTG?
Thx in advance for your response and for the great support you provide to us all.
Rds
Chav

Your software gives different ranges than HoldemResources Calculator's PSM model for Stars' hyper-turbo satellites (6-max, 50/50 payment for top 2, 500 stack 25/50/10 blinds). Shouldn't they both give the same results if they are based on the same model? How can I get more accurate results?

Yes and yes. Because of the "simulation" aspect of the algorithm, any effects on EV due to possible future stack distribution are going to get accounted for... even those that result from other players actions.

The current version limits the simulation to one future round. The next update will allow the users to increase the total simulation depth. That said, the effects of this are usually less than you might think... unless there is a stack on the edge of hitting the "danger zone", the effects of more future rounds tends to diminish very quickly.