Software and Tools Poker Forums

You don't need to purchase anything for Slice to work...it does allow you to load hands from Holdem Manager or PokerTracker 3 but that only works for Holdem & Omaha.

I haven't used it much but there is a database program that will track your hands (like Hold'em Manager or PokerTracker 3) for some mixed games. It is called fpdb http://forumserver.twoplustwo.com/168/free-software/free-open-source-poker-tracking-software-fpdb-stable-v0-20-1-testing-v0-20-906-27-aug-273001/.

At this time Slice doesn't work with fpdb (only HEM & PT3) but if people are interested, I can probably add support for it.

Just released the next version

This time I added two new features including equity graphing on the current street (previously only next street like PPT was available) and also an option to calculate equities on all turn and river cards (similar to the Scenario Analyzer that people liked in Poker Evolution).

Details are here: http://sliceeq.posterous.com/slice-v130-released-new-graphing-options
Download here: http://sliceeq.com/download/

Version 1.4 is out now and includes simulators for Razz, 5 Card Draw and 5 Card lowball (2-7). There is also now an ICM calculator and a fold equity calculator available.

More details available here: http://blog.sliceeq.com

would it be possible for any training vids on your software?

I have been meaning to do some videos (or hire someone else to do some) but just haven't had time yet.

I have a couple new features in the works that I hope to have finished before the end of the month and then I'm travelling/moving overseas over a period of weeks. As a result of that it could be a little while before I get to them

If there's anything specific I can help with in the mean time please feel free to ask away!

Hello and thank you for the great job you've done. Your project is the most ambitious and smart equity calculator I know. The thing I found especially helpful is the idea to apply this subtle, flexible, versatile syntax to stud games, which PPT failed to do. The Showdown hands tab is also precious in some tough calldown and RIO spots. (Btw, the feature I'd like to be added is the same stuff for any given street in Stud/Stud8 and Omaha, so that you can see the distribution of made hands/draws the opponent may have there.)
Although your software is worth way more than the price you charge, unfortunately, it still feels a bit buggy to me. Working with Range Enumerator for 2-7 SD and trying to work out the most common ranges one has to deal with in this game I encountered a problem trying to describe just any pat J or better (which I did as follows: "j-""j-""j-""j-""j-"{np!fs}!"jt987-"): plugging this in makes the program stall, though the similar expression works fine with Holdem (it enumerates all offsuit hands with two unpaired cards J or below which are not 0-gap connectors.)
Besides, I think I need some description of operators and filters priorities (and, thus, when you have to use brackets to get the range you imagined and nothing else).

Thanks for the kind words GG12.

The Stud/2-7 stuff has not been well stress tested like the Omaha & Holdem features so there are bound to be a few kinks to still work out. I will look into the issue with the 2-7 range that you posted.

"Besides, I think I need some description of operators and filters priorities (and, thus, when you have to use brackets to get the range you imagined and nothing else)."


Some precedence rules:

a ! b & c == (a ! b) & c e.g. Ac* ! Ad* & Kc* == (Ac* ! Ad*) & Kc*

a & b | c == (a & b) | c e.g. Ac* & Ad* | Kc* == (Ac* & Ad*) | Kc*

and filtering is always highest precedence but does not carry across operators. So for example in the Kc* | Ad*{np} the no pair filter would only act on the Ad.

Filters always have the highest precedence on the

Thanks for your responce. One more thing about 2-7: the program seems to treat drawing hands as 5c ones with random discards. It cannot be a big deal and usually doesnt affect your equity much, but still it would be just more natural to have it either way, that is to be able to specify discards as well.
A few more questions about syntax:
1)(BBBB ! AA) , MMMM{np} (example from the documention page)
As you pointed out ! > & > | = , so brackets seems unnecessary here (?). Btw, is comma completely identical to |, or there are some nuances? In this example you omitted asterisks behind AA, is it a general rule that all omitted cards will be set to * ?
2) How do weights interact with operators and filters in terms of precedence?

Sry for being so meticulous, just eager to grasp every single feature to use the program at full scale.

Simulated 100000 7 Card Stud 8/B Hands (Monte Carlo)
Simulation by Slice - The ev++ Equity Calculator

Player Equity Win Hi Tie Hi Win Lo Tie Lo Scoop Range

1 20.1 20.1 0.0 0.0 0.0 20.1 KhJs; Ks2c9d4h
2 79.9 79.9 0.0 0.0 0.0 79.9 L8, 3*, 22, 44-TT, qq ; 3cJc8s8c

In this hand Player2 went for a c/r on 6th. How to weigh his range towards trips here? I tried something like L8=70, ((3*,22, 44-TT, QQ)!*8)=30 for the down cards, but got the Missing ( bracket error message, which is very weird. L8=70, 3*, 22, 44-TT, QQ ! *8 = 30 expression does work, but obviously the subranges the program construct out of it are not the ones I want:

Simulated 100000 7 Card Stud 8/B Hands (Monte Carlo)
Simulation by Slice - The ev++ Equity Calculator


Player Equity Win Hi Tie Hi Win Lo Tie Lo Scoop Range

1 10.0 10.0 0.0 0.0 0.0 10.0 khjs; ks2c9d4h
2 90.0 90.0 0.0 0.0 0.0 90.0 (L8; 3cjc8s8c)=70.0% (qq!*8; 3cjc8s8c)=30.0%

Thanks for your responce. One more thing about 2-7: the program seems to treat drawing hands as 5c ones with random discards. It cannot be a big deal and usually doesnt affect your equity much, but still it would be just more natural to have it either way, that is to be able to specify discards as well.

Yes, I'm not happy with the way the draw equity calculators work right now and they will be changed in the future.

A few more questions about syntax:
1)(BBBB ! AA) , MMMM{np} (example from the documention page)
As you pointed out ! > & > | = , so brackets seems unnecessary here (?).

Yes brackets are unnecessary in this example. I often use them anyways since it makes it more clear to me when reading them.

Btw, is comma completely identical to |, or there are some nuances?

Identical. | is the traditional way of saying OR in computer science but people are already familiar with , from Stove.

In this example you omitted asterisks behind AA, is it a general rule that all omitted cards will be set to * ?

Yes. I found it made long Omaha ranges much more clear to, for example, write (Ac|Ad)&KK then (Ac***|Ad***)&KK**.

2) How do weights interact with operators and filters in terms of precedence?

Weighted ranges are sort of separate from the operators in that each sub range knows nothing about the other subranges. In your example:

L8=70, ((3*,22, 44-TT, QQ)!*8)=30

There should be no comma after the L8=70 and it should instead just be written:

L8=70 ((3*,22, 44-TT, QQ)!*8)=30

Which says give me L8 70% of the time and ((3*,22, 44-TT, QQ)!*8) 30% of the time. Think of the each weighted portion of the range completely separate from each other...it would be more clear to have them entered on separate input lines but space is at a premium unfortunately.

For the post below, it looks like you've uncovered a parsing bug with weighted ranges. There should be no bracket error there so I'll add it to the list of things to fix.

Weighted ranges are sort of separate from the operators in that each sub range knows nothing about the other subranges. In your example:

L8=70, ((3*,22, 44-TT, QQ)!*8)=30

There should be no comma after the L8=70 and it should instead just be written:

L8=70 ((3*,22, 44-TT, QQ)!*8)=30

Fortunately, with the convention you mentioned, theres a less cumbersome way to say the same: L8 = 70 3!8, 22, 44-77, 99, TT, QQ = 30, as !*8 in the former expression is aimed at just 38 and 88 in the hole. But... it still doesnt work properly: the output shows that the program ignores everything but QQ in the second subrange, so it looks like theres one more bug in parsing.
Theres also something wrong with the range enumerator for stud games: the program fails to understand (yy!5){np} ( = "4-""4-"{np} ) for the down cards in razz (Btw, it seemed a bit a strange to me that you have a tool to construct only all 3 down card ranges but nothing for the hole cards on 3d which is more common and useful).

PS It just came to me that it might be cool to have some sort of syntactic variables. That is a set of symbols, equal to * by default, that can be defined/resricted in a separate field to substitute for every their occurence in range expressions.

..ignores everything but QQ in the second subrange, so it looks like theres one more bug in parsing.

Yeah, I've got a fix for that and hopefully will have a release this week sometime which includes it.

Theres also something wrong with the range enumerator for stud games: the program fails to understand (yy!5){np}

The way you have written that is intuitive but at this point the filters enclosed in curly braces only apply to a single range and don't carry across brackets or operators. So you would want to write yy{np}!5{np}.

There is however a way to do what you want there. You can use global filters and write yy!5:np . Any filter after the : is applied to all the "sub ranges". So for example if you wrote yy{ss}!5:np that would get expanded to yy{ss&np}!5{np}.

(Btw, it seemed a bit a strange to me that you have a tool to construct only all 3 down card ranges but nothing for the hole cards on 3d which is more common and useful).

If you mean the range enumerator, just use the holdem tool instead. The stud equity calculator uses the number of upcards defined to determine whether to use 2 or 3 cards.

PS It just came to me that it might be cool to have some sort of syntactic variables. That is a set of symbols, equal to * by default, that can be defined/resricted in a separate field to substitute for every their occurence in range expressions.

Agreed that would be nice. I will consider adding that in the future.

There is now a trial Mac version of Slice available here: Slice Equity Calculator for Mac (direct link since website has not been updated yet).

I say trial because I have only tested it on my 64bit Intel SnowLeopard MacBook Pro but I hope it will work on other versions of OSX as well as 32 bit machines. If some Mac users are willing to download and test it out and report back to me what version of OSX they are using and whether it is a 64 or 32 bit system I would greatly appreciate it!

Thanks!

Screenshot of Slice Equity Calculator on Mac