I did 1 and 2 and after the restart PokerCruncher appeared in the Updates tab (along with one other app). What was happening was no apps appeared in the Updates tab. When I searched on PokerCruncher, it displayed an "Open" button but no "Update" button.

Signing out and back in caused a download of some other Apple apps, but not PokerCruncher. I wonder if it was a combo of 1 and 2. Either way, thanks for helping me with what turns out to be an App Store issue .

Psyched to try out the new features! Thanks again RJ.

Good, it sounds like you could now update this app. The moral is doing fresh resets, rebooting etc. often helps with system software issues.

You had missed about 5 app updates. If you want to see the details of each update see webpage:

http://www.pokercruncher.com/ipVersi...seHistory.html

Regards, -RJ

It's been a long time since the good issue above was brought up by Mr.Cyprine. The issue is, hand range programs across both Windows and Mac (including PokerCruncher-Expert-Mac) usually have their own unique syntaxes for weights in hand ranges, making it difficult for us to copy/paste hand ranges across programs. A couple of customers also wrote to me over email on this issue over the months.

App update V.12.2.1 went live today with I believe a pretty complete solution for this. PokerCruncher-Expert-Mac now supports several other popular hand range text syntaxes for weights (both import and export).

For example here's a simple hand range with weights in PokerCruncher-Expert-Mac syntax:

(a) JJ+, AKs; Weights: QQ:50%, JJ:25% ___________ (PokerCruncher-Expert-Mac syntax)

Now, the following other syntaxes for weights are also supported in PokerCruncher-Expert-Mac (both import and export):

(1) KK+, AKs, 50:QQ, 25:JJ ______________________ (e.g. Power-Equilab syntax)
(2) KK+, AKs, [50]QQ[/50], [25]JJ[/25] _____________ (e.g. Flopzilla, CREV, GTO+ syntax)
(3) KK+, AKs, QQ:0.50, JJ:0.25 ____________________ (e.g. PioSolver syntax)
(4) KK+, AKs, QQ@50, JJ@25 ______________________ (e.g. ProPokerTools syntax)
(5) KK+, AKs, 50.123456789:QQ, 24.987654321:JJ _____ (decimal number weights too)

To import into PokerCruncher-Expert-Mac, just paste the hand range's text (in any of the above syntaxes) into a player's hand range text field.

To export, click/select the hand range, then click the "Txt" button in the Range Editor view. The popup dialog will show all of the above syntaxes.

Please see the tutorial section on this feature for full details, including two important notes on differences in how weights are handled in PokerCruncher-Expert-Mac vs. in some of the other programs.

I hope I haven't opened up a can of worms here. Handling multiple syntaxes, while not technically hard, is tricky business where little things can go wrong e.g. when the syntaxes overlap etc. And it's a moving target, e.g. if the other programs change their syntaxes or add stuff going forward. But I decided to implement this because I know some of us do work with multiple programs e.g. an equity calculator and an EV/GTO program so this feature should be useful.

Fingers crossed that we'll be able to copy/paste OK across the various programs. Of course I'll fix things if needed and if they're mainline/reasonable syntax. Regards, -RJ

Can you run equities for double boards (split hold'em)?

Not directly, as in the user interface there are fields for entering only one board.

But you can sort of simulate Split Hold'em as follows: run two instances of this program (tutorial section on this feature), and enter the two boards in the two instances. Along with your/Villain's cards and ranges in each instance. You can then calculate in each instance to see your equity/stats on that board, and then take both sets of results into account in your betting action street to street. In each instance of the program, you'll need to enter the *other* instance's board cards as dead cards to take the full card removal / blocker effects into account.

So this won't be too convenient to simulate, but is probably do-able. I had never really thought of / designed for anything like this. It's hard to take different poker variants that might pop up into account when designing a program at the start.

I was wondering is there a way we could put different colors on one range chart, currently we can only highlight them as yellow, but I'd like to color checkcall/cheackraise, etc differently

This has been on my to-do / to-consider list for a long time, and has been suggested by more than a few people. I haven't implemented it yet because this feature isn't as simple/clean as it first sounds. For preflop-only ranges, this can be a clean/simple feature because flush draws aren't involved at that point, so all we want to do is put a given color on a given cell of the range grid (169 cells).

But postflop, when flush draws get involved, and backdoor flush draws, it's not enough to just put one color on a cell, because some of the combos in a cell may relate to the flush draw, and some other combos won't have anything to do with flush draws, so we'd need to put two or more colors on a cell because the cell's combos would be split up into different subranges (check-call, check-raise, check-fold, etc.). So we need to be able to add colors at combo-resolution, not just cell-resolution, and this leads to having/showing multiple colors on cells which could look confusing. And even for preflop ranges, we may want to color at combo-level e.g. if we want to put 5 of the combos of AA in our 3bet range and 1 combo in our smooth-call range. %age weights add a similar complication.

I'm not saying it's un-doable, anything is pretty much doable, but am just giving the reasons why I haven't implemented this so far. It's still on my to-do list. I hope to have a workable plan for this feature someday but can't guarantee.

Currently the method for working with subranges in this program is to save the subranges separately in the 200 range slots (use the Range Manager view to do this fast). You can name/prepare the range slots e.g. in your example "check-call", "check-raise", etc. Of course also save the starting range. Postflop, you can use the "Filter" button to generate your subranges automatically (based on stats / hand types that you select), so you don't even have to do the work of picking out the hands/combos that belong in each subrange yourself. I know this is a heavyweight and maybe not so convenient a solution for subranges, but that's the current method in this program, til I make a decision/plan on colors (maybe, won't guarantee).
Regards, -RJ

Any update on the filtering/colouring? As it stands what is the best way to break up ranges postflop for xing range calling range etc etc

No update on coloring subranges (it's still on my to-consider list), but filtering is there, and filtering combined with the new "Range Manager" view added in the last year, I think it's pretty convenient to create and save subranges postflop, in a fast and automatic way (without the need for manual editing of ranges). I'll give an example below.

First I'll give a screenshot of the Range Manager view at the bottom. It's showing the first 10 slots (out of 200), and I've named these slots per one of my usage setups. I use this setup to start with a range, then narrow it down on the flop, then narrow it down on the turn, etc. as the hand progresses, for both Hero and Villain. For your subranges usage pick a page of slots and name them as you need e.g. "Starting Range", "Fold subrange", "Call subrange", "Raise subrange", etc.

Now to break up ranges and create subranges postflop:

Enter the starting range(s).
Enter the flop cards.
Set DealTo = Flop.
Calculate.

Now say we're bet into on the flop and we want to create our fold, call, and raise subranges. Let's do the "raise" subrange: What kinds of hands from our range will we be raising? For simplicity let's say we'll raise all of our OverPair hands and all of our strong draws (flush draws and open end straight draws). To generate this subrange:

In the Stats view turn on the checkmarks of these stats, and only these stats: OverPair, FlushDraw, OpenEndStraightDraw, also DoubleGutStraightDraw.

Then click the "Filter" button. Of course do this with the range selected/clicked on the LHS. This generates this subrange automatically.

Then save this subrange into your "Raise subrange" slot. Using the RangeManager view to do this makes this fast because you don't have to go into submenus. Check out the RangeManager view closely as there are a lot of useful small buttons there for doing operations. Also check out the CMD+click and SHIFT+click shortcuts in this view for loading in ranges very fast.

Then go back to (load in) the original range again, calc again, and repeat the above process to generate the other subranges (with different stats turned on of course). Note that the subranges are generated automatically with no manual editing of ranges needed on our part. After you're done generating all of the subranges you can load them back in one by one and check out their combo counts to see if your subranges are balanced/weighted as you want, and if they add up to the total original range. You can then make some manual adds/subtracts on top if you want.

These sections of the tutorial have more info. on filtering and the Range Manager:

http://www.pokercruncher.com/ipPoker...ilterHandRange

http://www.pokercruncher.com/ipPoker...l#RangeManager

I'm still considering coloring, but I think using the above filtering process to generate subranges, and save them into separate named slots, is pretty fast without coloring. In fact, I think manually picking-out and coloring subranges/hands/combos would be pretty slow/tedious. But I'll keep thinking about coloring.

Do let me know if the above steps/process works for you and what's needed.
-RJ



"Range Manager" View:

The Range Manager view is shown at the bottom of the Range Editor view when you click the "RngMgr" button (which then changes to the "Built-In" button).

I watched the tutorial video earlier so I learned about discounting combos via the "View Card Reomval Effect" however I am wondering why it doesn't apply to the combo grid.



I would think in that example all combos with a club would not be selected. Any reason it behaves like this?

Thanks for giving a screenshot as that shows things very clearly.

Yes I had some reasons for why it works this way but I'll say that it is arguable, I can almost see it both ways. I'll give my reasons for why I went with the current behavior ...

The 4x4 combo grid shows what combos are or are not in the range according to the *original/baseline* definition of the range, i.e. according to the original intention of the range without taking card removal effects into account. To see card removal effects, we can turn on the ViewCardRemovalEffect setting as you have done in the pic, and we then see a combo count of 3 in the TT cell. We see 6 combos turned ON in the combo grid, so we know that 3 of the combos really aren't there due to card removal effect. So this gives us both views of the range, the original/baseline definition of the range, and the view with card removal effect, which I think is a flexible way of looking at the range.

Your range's text is "TT", which means all of the combos of TT, and the combo grid matches this which I think is consistent. If we really wanted only 3 combos we would have written e.g. "ThTs, TdTs, TdTh" as the range's text. Another example is if we enter "TT+", which is 5 hands and 30 total combos. In this range all 5 of the hands AA .. TT are defined in the same way, with all of their combos included. Just because there's a Tc on the board, that doesn't affect the original definition of TT in the range.

I'll give a counterexample of why the behavior you suggest may be undesirable and confusing. Enter a 9 card on the board. Now click on the 99 cell in the range grid to add this cell to the range. Per your behavior, only 3 combos get added (turned ON). Now go back to the board and clear the 9 card on the board. But then look at the 99 cell in the range grid, it will still only have just 3 combos turned ON (instead of 6). This isn't what we intended when we clicked on the 99 cell to add it. When we clicked on the 99 cell, we meant/wanted to add all of its combos.

This can be handled by adding an additional dimmed-out mode for the combos, to indicate they've been added but aren't really there due to card removal effect. But when we multi-select cells we already currently have dimming-out happening, so this would be a second kind of dimming out. I didn't want to go there, and thought the current behavior is the most consistent and simple and gives us both views of the range (the original/baseline view and the view with card removal effect).

But I've made many changes in this program over the years so nothing's set in stone. If I'm not thinking right here do let me know.

Thanks for the detailed response. It's not a huge deal for me I was more curious if it was a conscious decision or oversight. Sounds like it was the former. No problem for me. I think I'll be able to figure it out

Sorry for blasting you with questions but I have some others that I have not been able to answer myself (still trying to learn ALL of the features)

Is there anyway to export a range as a PNG/JPEG etc?
Is there a way to have multiple instance of the application running or a similar way where I can visually compare RvR next to each other?

Thanks again.

Yes conscious design decision. Because all 6 of those TT combos are part of the range according to how the range is defined/inputed.

But this is a good point and others have raised it too over the years. I'll see if there's anything I can do here in the future to make this clearer, like using a dimmed-out mode for the combos that don't apply due to card removal effect (but they will still be part of the range and will be on/off editable). May get complicated, won't guarantee a change here.


No problem at all, I'm here to answer. I appreciate your logical and clear presentation of questions/issues. Re. learning all of the features, I don't think it's a one day or even one week thing, but more a long term thing based on what you need to do at the given time.

No there's no in-app way to export a range as PNG/JPEG. For this you can just use the macOS system "Preview" app (it's in your /Applications folder), and do File menu --> Take Screenshot --> From Selection in that app, then go to the PokerCruncher app and capture the hand range grid.

But the standard and most useful way to export a range is via its text syntax, which of course you can do in PokerCruncher easily. All hand range programs on all OS's understand the standard hand range text syntax, so you can export/import ranges into other programs, and from other programs into PokerCruncher. You can copy/paste your ranges' text into forums, email to friends, etc., to share your ranges with others. So I think text syntax is the way to go for export/import, not image files.


Yes. But it can get tricky. See this section of the tutorial:

https://www.pokercruncher.com/ipPoke...InstancesOfApp

Note the "complication" mentioned. But if you're careful it works just fine, I've tried it.

Nice.

I decided to make an improvement for this card removal effect issue right away, it's live today in V.12.6.2, screenshot below.

In the 4x4 Hand Combos view, combos that aren't live due to card removal effect are now dimmed. But note that they still have a rectangle around them, indicating that they're still selected/added in the range (it's just that they're not currently live).

So in your example, all 6 of TT's combos still have a rectangle around them, meaning all 6 combos are selected/added in the range. But 3 combos are dimmed, meaning these 3 combos aren't live due to card removal effect.

Thanks for bringing this up again. It's been asked about before and I had postponed/by-design'ed it, but I think it's good to make this clarification in the Hand Combos view. I'll make this improvement in the iOS and Android versions of this app too in the coming weeks.

Awesome. Now thats what I call good service

It's been a long time coming, but PokerCruncher-Expert-Mac now has a "Color-Coded Groups In Hand Ranges" feature. This is in the latest app update V.13.1.1.

A couple of screenshots below. Here we've broken up the range into 3 groups: "Call", "Raise", "Fold". The 2nd screenshot shows the entire app window to show the entire scenario/situation.

You can click on the range grid and Hand Combos view to manually add/remove cells and hand combos to/from groups. You can also use the Filter-Add and Filter-Remove buttons in the Groups Editor view to automatically add/remove cells and hand combos to/from groups; this is what I did in this screenshot example to build the 3 groups automatically/fast.

Note that multiple groups/colors on a cell are supported, as this must be for this kind of feature, because in a given cell some hand combos can be in one group and some other hand combos can be in another group (as in this screenshot example). %age weights can also cause/need this (multiple colors on a cell).

There are more features/details, described in the new tutorial section on this feature.

Hope this feature works well in your/our usages. I'm open to feedback. -RJ

Just picked up the Mac version - been using iOS for a few years and loving it.

I did want to say that I was a little disappointed that I couldn't scale up the window/text. I see that there are three layout styles but the size is maxed out even fullscreen and the text is quite crunched on my screen. It's certainly workable and the value for study is immense. I guess I just want to confirm this is expected behavior.. I'm often scaling up text in most of my apps. Accessibility support would be awesome. Please see full screen image below.



I also noticed that all the buttons appear to be greyed out even when they are "active". Not sure if this is a Big Sur issue (m1) or something else. Looking further, maybe it's on purpose for the dark theme? I was mistakenly thinking even "Calculate" was disabled because I did something wrong at first. When you click it lights up to white. See basic view image below ("Calculate" button).



Thanks a bunch for giving us Mac users a solid tool!

Thanks for giving screenshots.
Yes this is as designed.

In apps that allow scaling text up/down, this almost always applies to the freeform text I believe, i.e. text in paragraphs or lines. The text on buttons and widgets usually doesn't change size. For example the Apple Mail app; changing the message text size doesn't affect the buttons at the top, and I don't see a way to change the buttons' text size.

In PokerCruncher-Mac a lot of the text is on buttons and widgets, and there is very little freeform paragraph text, so the usefulness of this seemed less. And, to have the text on all buttons and widgets also change size, is pretty hard imo, cause button/widget sizes would need to change and the UI layout would need to be adjusted pretty delicately just about everywhere, not trivial (maybe one reason even the Apple system apps don't do this). So another reason we went with the current design is implementing full control over text size would be pretty hard to implement.


This is also by design, looks to be the way macOS renders the buttons in dark mode by default. I'm also looking on macOS Big Sur. For example in the Apple Mail app, the buttons at the top (GetMail, NewMessage, etc.) are gray in dark mode and turn white when you click on them. Now that I look at it again, maybe the buttons are a smidgen dimmer in PokerCruncher-Mac, but that may be an optical illusion; in our implementation we're relying fully on the default system behavior.

Sorry I said "by design" for everything. I'll think but I don't see an easy way to change any of these looks. If there is an easy way I'll consider it.
Thanks for using the Mac-Expert version. Regards, -RJ

Great points - thanks for the responses.

Yeah I'm aware that adaptive layouts are not easy - especially if not originally designed that way. I've had similar struggles adapting iOS to iPad in the past. SwiftUI made this much easier for me. I think the main issue I have is due to the large pixel density of my monitors - the entire app feels small. I mean the largest mode fits about a quarter of the screen.

But certainly I realize if you wanted to expand to fill when full screen - every single element would likely need some adjustments for adaptive layouts. I get it's a ton of work - but still wanted to bring it up anyway.

The main difference I see with Apple native apps in dark mode is that they have a hover color that 'lifts' the button to know it's clickable. I think that was probably what threw me off - the buttons threw me off. And I'm aware this is nitpicky.

A question with it though - I dont see how to switch to Light Mode if my system is set to dark mode. Is there a way to switch or is it strictly auto by system?

We're getting into details of UI design here, kind of out of scope. Sometimes I wish I just said "thanks for suggestion, we'll consider it for future releases" . But I like giving full answers and discussing with people who've shown they're knowledgable, so ...


Your screen is very large. What's happening here is, PokerCruncher-Mac just doesn't need a screen this large. Forcing it to expand in all directions to this large a screen would just result in all the UI elements being very sparsely laid out, which I think would look weird. In fact our eyes would have to work harder going left-right and up-down to see everything, whereas now our eyes don't have to travel very far to absorb everything in the compact window, helping us to work faster.

There are two kinds of apps - apps with unlimited content, and apps with fixed content. For the first kind of apps (unlimited content), e.g. text editors, drawing programs, web browsers, huge screens help because you can write more, draw more, see more content. PokerCruncher-Mac is basically fixed-content; you can enter at most 10 players, the range grid is fixed at 13x13, the card deck is fixed, etc. For these kinds of programs huge screens add less benefit imo, and there's really no need to make the program expand fully to the entire huge screen.

I'll give two examples from Apple themselves - their system Calculator app, and their SystemPreferences app. Their Calculator app, when you click the full-screen button the app's window does not expand out to full screen. Their SystemPref app doesn't even have the full-screen button enabled. I believe PokerCruncher-Mac is more like these kinds of apps, mainly fixed-content, so it's better to keep the window compact as it is currently.


No problem, it's worth discussing.
I wish Apple provided a "2x" button or "1.5x" button on macOS, like they do on iPad, to just scale up any app. I think they didn't do this on macOS because it would result in grainy UI, or they wanted a consistent UI-elements size feel across all apps, or some other good reason.


Good point, the button highlighting on hover does help. PokerCruncher-Mac's buttons don't have this, I think because I went with the most basic / vanilla style text buttons. I'll see if I can add the highlighting in the future, but won't promise it, because as it is currently I think people will still try clicking on the Calculate button etc. and will see that the buttons are active.


No, the app doesn't have its own private dark mode setting. What I gather is that apps aren't supposed to have their own private settings, but rather respect the system-wide dark mode setting, for consistency, vs. an app doing its own thing. For example I haven't seen private dark-mode settings in many standard apps like Apple's.

Thanks for feedback, some good points were brought up, and I hope I gave/have some good reasons for them : ). Regards, -RJ

Thanks a ton again for taking the time… I really appreciate it and clearly you are a dev who cares. Your responses make a lot of sense.

Just starting to dig into all the advanced features and excited to get studying!

BR

Thanks for supportive words.
Welcome to the Mac-Expert version.
Just in case you haven’t seen the tutorial & videos page yet:

https://www.pokercruncher.com/ipPoke...rTutorial.html

There’s a (long) written tutorial that should help with study (over time).
Of course the Mac-Expert version can do everything on this page (including the iPhone screenshot sections).

There are also some videos made by some pros/coaches at the top of the page. But the written tutorial is the complete features description.

Hello,

I'm pretty new to studying poker, but appreciate having this tool. I've been using for a couple months now and haven't even gotten deep into some of the exciting features like the equity dist. graphs and heatmaps. Just read through this whole thread and see that these are just some of many upgrades, so thank you!

I have been doing some math workbooks analyzing how ranges hit flops. I notice that the frequency with which Poker Cruncher predicts two pairs on the flop (starting with a 15% range) with is much higher (7.5%) than what the answer key to my workbook predicts. It seems the author (Splitsuit) is using Flopzilla and is getting 1.2% frequency of two pair.

Is this just due to differing definition of two pairs? (I.E. Poker Cruncher counts a paired board and a pocket pair as 2 pair but Flopzilla puts that in a different category? I tried toggling the make hand and hit hand button, but that only changes the two-pair frequency on Poker Cruncher by a little bit--7.5% with "hit hand" enabled, 8.7% with "make hand" enabled.) Or am I making a mistake in how I am inputting data or reading results? Thanks in advance for the guidance.

Here is a screenshot of how I am inputting a scenario and my results


And here is a comparison screenshot from the author of my math workbook solving the same scenario.

Thanks for supportive words on this program.


Thanks for a clear description with screenshots from both programs.


This is exactly it; you figured out why right off the bat.

PokerCruncher gives "make hand" stats and "hit hand" stats.

1) "make hand" stats - This is the textbook definition of the stats and there can't be a difference between any programs (other than if bugs) because it's unarguable.

2) "hit hand" stats - These are defined subjectively by the various programs in this space, to give more useful numbers for the stats. E.g. if you have QJ and the board is 99772 then you've made TwoPair but haven't really hit anything.

Note that PokerCruncher gives both "make hand" stats and "hit hand" stats but I believe FlopZilla only gives "hit hand" stats (not sure on this though).

What's happening is that PokerCruncher uses a slightly more lenient definition of "hitting TwoPair" than what FlopZilla is using. As you pointed out, in PokerCruncher if you have 66 and the flop is 884, then you get credit for hitting TwoPair. But in FlopZilla you don't, which is why it gives such a low number for TwoPair in your example, 1.2%.

My reasoning for the "hit" stats is that if you're using both of your hole cards in a full/effective way to make the hand in question, then you've hit that hand. In the above example 66 is using both hole cards to hit/make TwoPair on this flop. But if you had A4 then you wouldn't get credit for hitting TwoPair.

I can see why FlopZilla doesn't give 66 credit for hitting TwoPair here, but I can also make a case for why PokerCruncher does give credit (above explanation), hence I had said it's arguable. I am biased of course, but I like the PokerCruncher hit TwoPair definition better. If you have 66, or say JJ, on this 884 flop, you're certainly using both of your hole cards effectively, much more effectively than say A4 is, so it seemed to me that 66, JJ, etc. should get more credit for hitting TwoPair here than A4.

I'll give another, higher level, reason why I like the PokerCruncher definition here better. In general it should be harder to hit the more rare stats than the less rare stats. So for a generic type range (and your roughly Top15% of hands is a pretty generic range), the rarer/harder stats 3OfAKind, Straight, Flush, Quads etc. should have much lower values than OnePair and TwoPair. But if you look at the FlopZilla 1.2% value in your screenshot for hitting TwoPair here, that's much lower than 3OfAKind (5%). This seems odd/wrong to me; why should the rarer/harder stat 3OfAKind be easier to hit than TwoPair for this pretty generic Top15% range? So if there's a problem here imo it's in FlopZilla not PokerCruncher. Or there may not be a problem in either program because as I said the meaning of "hitting" a stat is subjective not textbook-definition.

But if they're happy over there on Windows/FlopZilla with their very low hitting TwoPair numbers, I'm not going to argue with them and just let them be happy.

This hit stat thing is arguable though; I'm open to discussing if you think there's a problem here.

Regards, -RJ