Yeah, you're right, there is something wrong with those numbers. There was a bug in the last version that could make the equilibrium finder become unstable (especially with deep, even stacks). This is already fixed for the next version which will be out either today or tomorrow.

Thanks for the feedback!

FYI, there is a new version 0.9.9... mostly minor fixes. I have postponed the data update that I warned about before...

Also, there was a 0.9.8 version up briefly, but it will not run correctly (it will try to load a file that doesnt exist.. doh!). So if you downloaded 0.9.8, you will have to upgrade to 0.9.9 before it will run. Sorry about that.

Hi guys... version 0.9.10 is released! Lots of good stuff in this one. Not really new features, but many improvements to the math engine.... better processing speed and better quality to the results in many spots. A few math bugs crept in somewhere around v0.9.6, so if you've been using an earlier version and thought some of the results looked "weird" (like RiverJohn above), you should definitely give this one a shot and see if things aren't a lot better.

This version requires all new data so, as I warned about earlier, there will be no 0.9.10 upgrade package. This was necessary to pick up some performance and to lay the foundation for some very exciting future features...

Enjoy!

Why are there differences between the results in the Table View and the Equilibrium Strategy Tree? For instance:

Structure: 70/30
Blinds: 200/100
BTN: 3500
SB: 2000
BB: 2000

In the table view it says the BTN shoves 18,9% whereas EST says it is 47,2%. The difference is huge and I doubt the BTN ought to be as tight as 18,9%. Which is the "correct" result now?

There's a couple things going here...

First, we should keep in mind how the different ranges are calculated:

The ranges in the "Equilibrium View" are approximate NE solutions based on the players being restricted to linear hand ranges.

The Hero's range in the "Table View" is a perfect response to the opponents and is *not* restricted to a linear set of hands.

Given that, when the Hero's range is very different from the equilibrium range for that seat it usually means that the "perfect" range is very sensitive to the ranges of the opponents. That is, small changes to the opponents ranges will result in a large change in the correct response for the Hero.

We can see this in effect in this hand... if you edit the calling ranges for the BB or SB and make them just a little bit tighter, then the Hero's range very quickly becomes very wide. Set the SB to 6.2% and the BB to 9.4% and now the Hero's calculated response is 49.9%. Just 2-3% change in the opponents ranges equate to over 30% change for the Hero.

So, the bottom line is that the Hero range in the Table View is "more correct"... but that correctness is dependent on the accuracy of the other players ranges.

Make sense?

Can you give us some info about exciting future features?

In situation where someone is betting and we can call or not, for players that are after us we can modify only overcalling range. It would be good that we could also modify their calling range (when we are folding) cause some bubble decisions are really dependant on "what happens when we fold" scenario.

Oh, you know, just some stuff that's going to put the analysis even farther ahead of what any other program can do... no big deal.

I'm working on this as we speak...

That said, you can actually edit all those ranges now, just in a roundabout way by changing the Hero position and Villain actions to expose the response range you're interested in modifying. When you edit a range, the changes stick until you "re-Solve". So, even though you cant see a particular part of the "range tree" because of where you set the Hero position at the moment, its still affecting the calculations.

I tried downloading the new version and got a message saying 'installer integrity check failed. Possibly due to damaged or incomplete download."

That message is coming from the 3rd party installer I've used (NSIS)... sounds like the download was corrupted somehow. You might try clearing your browser cache and re-downloading.

Bug:

Payout structure
1st: 1000

Blinds
Doesnt matter

Players
1500
1500
1500

Action:

Solve game

Edit game

Add one player

Solve game

Program crushes

I downloaded the 9.10 version and it was working fine then I go to load it up today and it says. 'This beta version expired. Please download and install upgrade' Kinda weird since I have the newest version.

Ah, whoops. Sorry about that... I havent uploaded the newest version to the download servers. Yet... they should be up within a couple of hours from now.

Okay.. there is a new version (0.9.11) up now.

Not a lot of big changes, at least none that are going to be very visible... there is a new "Details View" tab, but this is mostly an UI experiment at this point and does not offer much to the user right now.

A couple potential crash bugs are fixed. I was unable to reproduce the bug ginandbread reported, so hopefully that means that one is fixed as well.

Enjoy

I tried upgrading and it did not work.

Got a message saying

'Error opening file for writing:

C:\Program Files (x86)\Belmont Advanced Industries\Sng Solver\SngSolver.exe'

Then it gives the options to abort, retry, or skip the file. I tried skipping and it doesn't work.

Hmm... that sounds like the kind of error you'd get if you had the program already running when you tried to upgrade. Maybe check the task manager to make sure that you didnt leave it running (I do that all the time myself). In particular, check the "processes" tab to make sure that "sngsovler.exe" doesnt appear in that list. If it does, right-click and "end process".

If you cant get the upgrade installer to work, you could try to "uninstall" first and then re-install from the "full" installer package.

I cleared my cache, re-downloaded the upgrade and it worked.

For 2 players, ranges are different if payout is 1st=1000 and if payout is for example 500/300/200.

I have found the cause of this... an update with a fix will be coming shortly.

Where is the HH-Import feature on your To-Do-List? Waiting for it since the first open beta version. Really like SNG Solver so farbut HH-Import would make it awesome.

Are you going to implement limpers/raisers (like they have in SNG Wiz)?

wtf?

The top of my to-do list is something like this... 1) make sure the analysis solid and stable, 2) make sure the UI is effective, and 3) add HH import ...

Once I get the "details view" implemented and sorted, I'll feel comfortable moving on to getting HH import in.

I do indeed have plans for adding limper/raiser support. In fact I have a very *big* plan for this... but I'm not ready to let the cat out of the bag just yet.

Oh, just wanted to see if anyone actually reads the license agreement.

Yeah, this licence agreement almost killed me

I think sng solver gives much better results when short handed but for >7players, even 6 players, complete calculation takes too long and future hands aren't that important then so all that calculation becomes pain in the ass.
Do you plan to get calculations when Advanced ICM mode is off better? My assumption is that you neglected that part cause obviously Advanced ICM is priority.
My suggestion is if you want someday to have an all-around program you must solve this problem also cause I think ranges are visably off from Advanced ICM, and when >6players Advanced ICM becomes similar to sng wizard calculations.
So from comparing Advanced ICM => SngWiz => Advanced ICM off, I think for now it's better to use SngWiz then your Advanced ICM off mode (for >6,7 players)
Calling an allin resteal would also be a great thing to add.



Here is a short program for uploading HH (only pokerstars) to sng solver I use,
it fills payouts, blinds and stacks and clicks "Solve";
http://www.mediafire.com/?co9aiew3g6n3kb0

(From other thread, I've been suggested if you are suspicious about software, check on virustotal.com but I guarantee is safe)

The way the algorithms work, processing time increases geometrically with respect to the number of players... with each player added, processing takes about 3.5 times longer. As you observed, with a typical PC, things really start to "blow up" around 6 or 7 players.

How much time do you consider to be a "pain in the ass" where it doesnt seem worth it anymore?

We haven't really talked much about performance in this thread yet... so here's some random facts that might be interesting:

- I have a PC with an Athlon x64 4400+ (dual core, 2.2ghz) in it that I consider to be a "low end" machine. For a 6 player solve it takes 19 seconds... for a 9 player solve it takes almost 13 minutes.

- My development machine has 2 quad core Xeon CPUs (also 2.2ghz) and it takes 6 seconds for a 6 player solve and a little over 3 minutes for 9 players.

- on most systems, performance is going to be bound on memory speed. So, upgrading a CPU would only show modest gains if it doesnt accompany an increase in memory bandwidth

- I make full use of Intel's SSE3 instruction set. I have already written SSE4 enabled code, but because memory bandwidth is the limiting factor, it wont be as big a benefit as it theoretically could.

- The core of SnG Solver is written in C and hand optimized SIMD assembly. Despite being memory bandwidth bound, on my system, it runs with a sustained CPI (cycles-per-instruction) of around 0.6. That is very good. In other words, for any of my would-be competitors that would try to duplicate what SnG Solver does in Java, C#, or some other managed language: good luck with that.

- I already have a version of SnG Solver that runs the solve on the GPU. On my very modest nVidia GTS 450, its good for about a 5-10x speed increase over my 8 CPU cores. So like, yeah, GPU computing is going to be a part of the future for SnG Solver in a big way.



I realize that SngWiz has some features that SnG Solver doesnt have (yet), but could you elaborate on why you think the Wiz calculations are better than "Advanced ICM Off"? With Advanced ICM off, SnG Solver's results should essentially be identical to Wiz.


Absolutely. I have a plan for handling other actions besides just push/fold and consider it a high priority.


Excellent! I had no idea I've already spawned a 3rd party app scene. Did you write this?

Not working 4 me ...