I have been using this excel spreadsheet for all my Probability calculations. It just breaks down the chances of a symbol showing up for each die as a % and goes from there

My players tend to role really well with the purple

I think that's more dice bloat than negative dice. it is making an array of size approx 12^x, where x is the number of dice, after all. but you're right. using the same "calculate all different combinations, then pick one" that the calculator uses is a waste of space. I shall change the implementation soon.

(you'll notice if you calculate anything over 8 or so dice it chugs immensely. 12^8 = 429,981,696, after all. so 500 million strings in an array... not good. )

Yes, it is needing a huge amount of memory because of all the possible combinations that come with these dice. Since they aren't simply numeric and results of one counteract another to get the final result it can churn. I tried something similar using my own dice roller app (see signature) and found that outside of 3 or 4 total dice, the combinatorix were just huge. I wasn't using a matrix, instead was iterating through the possibilities.

Yeah, I'm going to see if I can make an iterating one instead, it'll take... I think 4*(x!)^2 space instead of 12^x + 4*x^2 space. Still terrible, but, eh, what can you do.

I fixed it. It is now MUCH faster, for the trade off of being about 30 lines longer.

Dice roller is faster as well, but ironically even shorter.

Feel free to make fun of my regex and nested blocks. I'll probably sort that out later

In mine, I created a new 'die' type (for example) boost-boost. It has 11 sides, with a probability distribution for each side. If it were a normal D6 it would look like: (where PD is the probability distribution, or number of results to score for that 'face')

die

face PD

2 1

3 2

4 3

5 4

6 5

7 6

8 5

9 4

10 3

11 2

12 1

The result of this optimization is that a D6 would have 11 calculations rather than 6 times 6 = 36.

GG (two greens) has only 15 'sides' rather than 64 for a 76% reduction in total iterations,a nd so on.

You can create a purple-purple, and a purple-purple-purple and a purple-purple-purple-purple 'die' (and so on) that provides a massive contraction in the number of calculations required.

For example, my recent hyperdrive experiment with YYG PPPPP would naively require 37,748,736 iterations. With this sort of optimization it requires many many less. It takes less than 2 seconds in Ruby.

With 4 dice of:

YY with 22 instead of 144

PPPP with 45 instead of 4096

G with 8 'sides'

P with 8 'sides' (hmmm, I should summarize 5 P )

has only 63360 iterations required. A savings of 99.83%

I fixed it. It is now MUCH faster, for the trade off of being about 30 lines longer.

Like many, many orders of magnitude faster! YAYAYAYAYAY!

But I did notice something a bit weird:

$ ruby dicecalculator.rb APPPPDCB -T:S
"S"
Max Success: 11, Max Advantage: 12
Max Failure: 4, Max Threat: 4

++++RESULTS for Dice Pool: PPPPACDB++++
Total Chance of Success: 91.08%
Total Chance of Advantage: 83.83%
Total Chance of Threat: 6.5%
Total Chance of a seeing a Failure Symbol: 2.93%
Total Chance of Reaching Target (S): 84.6%
Total Triumph Chance: 29.39%
Total Despair Chance: 8.33%
+++++++++++++++

So, how is it that "Total Chance of Success: 91.08%" while "Total Chance of Reaching Target (S): 84.6%"?

I fixed it. It is now MUCH faster, for the trade off of being about 30 lines longer.

Like many, many orders of magnitude faster! YAYAYAYAYAY!

But I did notice something a bit weird:

$ ruby dicecalculator.rb APPPPDCB -T:S
"S"
Max Success: 11, Max Advantage: 12
Max Failure: 4, Max Threat: 4

++++RESULTS for Dice Pool: PPPPACDB++++
Total Chance of Success: 91.08%
Total Chance of Advantage: 83.83%
Total Chance of Threat: 6.5%
Total Chance of a seeing a Failure Symbol: 2.93%
Total Chance of Reaching Target (S): 84.6%
Total Triumph Chance: 29.39%
Total Despair Chance: 8.33%
+++++++++++++++

So, how is it that "Total Chance of Success: 91.08%" while "Total Chance of Reaching Target (S): 84.6%"?

Edge case issue in my Target functionality. My apologies. It's fixed now. Thanks for letting me know. xP

And now Triumph and Despair are added to eXpanded probability view and target functionality. Now you can see the specific probabilities of different values of Triumph and Despair! (And since this is all programming by the seat of my pants, keep in mind that bugs are still a possibility. )

In mine, I created a new 'die' type (for example) boost-boost. It has 11 sides, with a probability distribution for each side. If it were a normal D6 it would look like: (where PD is the probability distribution, or number of results to score for that 'face')

die

face PD

2 1

3 2

4 3

5 4

6 5

7 6

8 5

9 4

10 3

11 2

12 1

The result of this optimization is that a D6 would have 11 calculations rather than 6 times 6 = 36.

GG (two greens) has only 15 'sides' rather than 64 for a 76% reduction in total iterations,a nd so on.

You can create a purple-purple, and a purple-purple-purple and a purple-purple-purple-purple 'die' (and so on) that provides a massive contraction in the number of calculations required.

For example, my recent hyperdrive experiment with YYG PPPPP would naively require 37,748,736 iterations. With this sort of optimization it requires many many less. It takes less than 2 seconds in Ruby.

With 4 dice of:

YY with 22 instead of 144

PPPP with 45 instead of 4096

G with 8 'sides'

P with 8 'sides' (hmmm, I should summarize 5 P )

has only 63360 iterations required. A savings of 99.83%

Figured I should respond to this, that yes, that's what I meant by my optimization to 4*(x!)^2 (which should be (2*x)^2, I think.). So it runs in O(n^2) instead of O(12^n). When I made it, I was going to do that, but I was too excited about the product function doing it in 3 lines, so I made a horrible monstrosity of demonic RAM eating hunger. Science is fun!

There is now a branch of the script called "group-targeting". It's only for positive dice right now, (sorry brad. XP), but it will return the probability of reaching any one of the target success/advantage/triumph pools that's been input.

So if you wanted to know how to, say, crit twice with both shots of a linked 1, crit 3 weapon, you can input the target group:
-1 Success, 8 Advantage

-1 Sucess, 1 Triumph, 5 Advantage
-1 Success, 2 Triumph, 2 Advantage
(which looks like "-G:SAAAAAAAA.SRAAAAA.SRRAA" when input because I have no grasp on readability.)

And you'll get the probability that you'll reach any one of those three thresholds! (It's 0.07% for the dice pool YYGPPB btw)

Once again, I apologize if there are any errors. I've been a bit more rigorous with my checking than previously (heh heh ^.^") but some may still occur.

There is now a branch of the script called "group-targeting". It's only for positive dice right now, (sorry brad. XP), but it will return the probability of reaching any one of the target success/advantage/triumph pools that's been input.

I just did a "git pull upstream master", and I'm not seeing this branch. Did I do something wrong?

There is now a branch of the script called "group-targeting". It's only for positive dice right now, (sorry brad. XP), but it will return the probability of reaching any one of the target success/advantage/triumph pools that's been input.

I just did a "git pull upstream master", and I'm not seeing this branch. Did I do something wrong?

It's a branch right now, so you can't pull it from the master, I believe. You'll have to checkout the new branch instead of fetching from the master branch.

It's a branch right now, so you can't pull it from the master, I believe. You'll have to checkout the new branch instead of fetching from the master branch.

Oh, right. Sorry, for as long as I've been doing git and github, this is actually the first time I tried to pull a particular branch from an upstream repo.

Thanks again!