DISCLAIMER ABOUT RATES

Gumi does not officially publish the rates used by this calculator.

Rates are obtained through a mix of the rates of the Japanese version of the game (which *are* published) and estimates from surveys conducted in /r/FFBraveExvius. While these rates are useful in making predictions, they do not hold the same certainty as official rates would, and the lack of published rates means the rates in effect may be changed arbitrarily and without notice from Gumi. **Use at your own risk.**

Number of Regular Pulls

(Including tickets, dailies and 500 lapis draws)

Number of 10+1 Pulls

(5000 lapis a pop!)

Guaranteed 4★ Tickets

(Only from special rewards and bundles)

Use rates:

JP RATE

◀

▶

Odds of getting **at least one**
5★-base banner units

Multiple 5★ on banner?

One not enough?

Show expected?

• • •

Default results (GL estimated) are based on rates available here: http://exvius.gamepedia.com/Summon. **I have not personally verified these rates are correct,** or that the probabilities are distributed the way I understand them to be, so take everything with a grain of salt and use at your own risk. No guarantees, warrantees, or recipes are implied by these numbers!
*appears* to have finally given us identical rates to JP. Here's how they compared **prior to the 3% upgrade**:

**Remember, these odds represent likelihoods only.**

A**95% chance** will **feel like 0%** if you happen to hit **an unlucky 5%**. (This is the same odds as rolling a 1 on a d20, which anyone who plays D&D will tell you happens more often than you expect.) As always, praise be to RNGesus.
**troll crystals** in Global. This means if you pull a gold crystal it is guaranteed to be a 4★-base unit, and if you pull a rainbow crystal it is guaranteed to be a 5★-base unit. (Before the update, gold and rainbow would potentially pull from any of the 4★- and 5★-*capable* units, which are much larger pools including all of the common (and crappiest) blue-crystal units.) So if you see a gold or rainbow crystal, the unit you get is guaranteed to be in the same tier as the banner unit. It is *not* guaranteed to be the one you want, though.

• • •

Japanese rates (JP Old and Current) are rates published by Alim. With the 3% Rainbow upgrade, Gumi

Rate | Regular pulls | Bonus pulls |

JP Old | Appears identical to GL Old | 50% of golds on-banner, vs. estimated 25% in GL Old |

JP Current | Rainbows 3% (1% on-banner), blue reduced to 78% | Unchanged from Old |

Again, **GL rates are only estimated as Gumi does not publish official rates.**

• • •

For large values the calculator may report ~100%. Obviously nothing with probability is exactly 100%; this is due to numerical imprecision in the calculations. But if it helps, I will gladly wager you a steak dinner versus five of your dollars should you try for a ~100%-likely combination of pulls and not get the expected result.
• • •

A

• • •

As of the February 23rd, 2016 update, we no longer have so-called
Normal Crystals

The following are the - Blue crystals drop at
**78%** - Gold crystals drop at
**19%** - Rainbow crystals drop at
**3%**

The overall probabilities are estimated as follows:

Crystal | Unit type | On banner | Off banner | Total |

Rainbow | 5★ | 1% | 2% | 3% |

Gold | 4★ | 4.75% | 14.25% | 19% |

Blue | 3★ | 19.5% | 58.5% | 78% |

• • •

Bonus Crystals

The bonus crystal you get as part of a 10+1 pull or by using a guaranteed-4★ ticket follow a different - Gold crystals drop at
**95%** - Rainbow crystals drop at
**5%**

Crystal | Unit type | On banner | Off banner | Total |

Rainbow | 5★ | 3.75% | 1.25% | 5% |

Gold | 4★ | 47.5% | 47.5% | 95% |

Basic Math

Ignoring the 10+1 pulls for now, each pull is an
1.0 - (chance of failure)^{number of attempts}

• • •

10+1 Pulls

10+1 crystals introduce the "bonus crystal", which is always the first crystal shown in your 10+1 pull. As explained in the stats section earlier, these crystals use their own distribution, such that you have:
**47.25%**chance of a 4★-base banner unit (bonus crystal only)**3.75%**chance of a 5★-base banner unit (bonus crystal only)

1.0 - 0.99^{10} × 0.9625 = 0.1295

So every 10+1 pull gives us approximately a From here, it's a simple matter to combine these two drop rates:

1.0 - 0.99^{regular pulls} × 0.8705^{10+1 pulls}

This is the • • •

It is left as an exercise to the reader to determine how the other statistics are similarly calculated. (You can always view the JavaScript in this page to see how it's done!)
Multiple Successes

Say we want more than just 1 banner rainbow. We want 2, or 3, or even 5 banner rainbows (real whale territory here). How do we go about solving that?
If we examine a probability tree for a number of pulls (let's do four), we can count the number of successes we had along the way while traversing from the top to the bottom to reach each final outcome: Even though we take different paths to get to the bottom, the odds of getting to the same total successful outcomes is going to be the same each time:

# of successes | Odds a path will lead there |

0 | p_{failure}^{4} × p_{success}^{0} |

1 | p_{failure}^{3} × p_{success}^{1} |

2 | p_{failure}^{2} × p_{success}^{2} |

3 | p_{failure}^{1} × p_{success}^{3} |

4 | p_{failure}^{0} × p_{success}^{4} |

(This is true so long as we aren't mixing pull types, e.g. all four of our pulls are just single tickets, or just 10+1 pulls.)

Ok, great, this is already familiar from how we calculate at least one success as being 1.0 - p_{all failures}. But that works because there's only one path that leads to all successes or all failures. How do we get something meaningful for the guys in-between, where there's more than one path that leads to that outcome?

If we count the number of times a path leads to each outcome, we see the following:

# of successes | Path odds | # of paths |

0 | p_{failure}^{4} × p_{success}^{0} |
1 |

1 | p_{failure}^{3} × p_{success}^{1} |
4 |

2 | p_{failure}^{2} × p_{success}^{2} |
6 |

3 | p_{failure}^{1} × p_{success}^{3} |
4 |

4 | p_{failure}^{0} × p_{success}^{4} |
1 |

Look at all familiar? You're seeing the 5th row of Pascal's Triangle.

Since the odds for each repetition of a path are the same, we can just multiply by the number from Pascal's Triangle to get the combined odds of reaching any particular number of successes:

# of successes | Odds of exactly that many successes |

0 | 1 × p_{failure}^{4} × p_{success}^{0} |

1 | 4 × p_{failure}^{3} × p_{success}^{1} |

2 | 6 × p_{failure}^{2} × p_{success}^{2} |

3 | 4 × p_{failure}^{1} × p_{success}^{3} |

4 | 1 × p_{failure}^{0} × p_{success}^{4} |

We now know the odds of getting *exactly* 0 successes, *exactly* 1 success, *exactly* 2 successes, etc. Fortunately it's very easy to turn these from "exactly" into "at least":

p_{at least N} = 1.0 - p_{exactly 0} - p_{exactly 1} ... - p_{exactly (N-1)}

The great thing about this is that computationally it's not much worse than what we were already doing. Even if some jerk enters 1,000 pulls for a probability tree that's 1,000 levels deep, we only need to care about the first N - 1 possibilities for number of successes, and so long as we keep the maximum value for N relatively low (we use 5), the number of pulls can be as high as desired without requiring additional computation.

• • •

Mixing pull types

Wow, you must really want to get into the guts of this. Okay.
What we have so far works just fine so long as we're using *just* tickets, or *just* 10+1 pulls, or *just* 4★-guaranteed tickets. What happens when we want to mix types?

Let's say we're going to combine 2 pulls of 4★-guaranteed tickets with 4 pulls of regular tickets. You can imagine the two probability trees being grafted onto each other:
If you draw this and actually write in the probabilities at each stage, you'll see that any two paths that lead to the same number of successes are *no longer guaranteed to have the same probability*. Well, shoot.

In the end it's not actually *that* much harder to make this work, but we need to track the pull types separately and merge the two trees. For this reason, we no longer treat 10+1 pulls as their own unique type of pull, but instead split them into 10 regular pulls and 1 bonus crystal pull. This means we only have to track and merge regular pulls and bonus pulls, which makes things a lot easier.

Let's take the two probability trees for 4 regular pulls and 2 bonus crystal pulls: This gives us two success tables:

# of successes (regular) | Odds of exactly that many |

0 | 1 × p_{failure}^{4} × p_{success}^{0} |

1 | 4 × p_{failure}^{3} × p_{success}^{1} |

2 | 6 × p_{failure}^{2} × p_{success}^{2} |

3 | 4 × p_{failure}^{1} × p_{success}^{3} |

4 | 1 × p_{failure}^{0} × p_{success}^{4} |

# of successes (bonus) | Odds of exactly that many |

0 | 1 × p_{failure}^{2} × p_{success}^{0} |

1 | 2 × p_{failure}^{1} × p_{success}^{1} |

2 | 1 × p_{failure}^{0} × p_{success}^{2} |

And we still want fundamentally the same thing as we did before:

p_{at least N} = 1.0 - p_{exactly 0} - p_{exactly 1} ... - p_{exactly (N-1)}

So what's the probability of exactly 0, exactly 1, exactly 2, etc? Well, it'll be the probability that, between the two trees (let's call them A and B), that we still hit exactly 0, 1, 2, etc. after traversing both trees.

# of successes (combined) | Odds of exactly that many |

0 | p_{A0} × p_{B0} |

1 | p_{A0} × p_{B1} + p_{A1} × p_{B0} |

2 | p_{A0} × p_{B2} + p_{A2} × p_{B0} + p_{A1} × p_{B1} |

- Exactly 0 can only be arrived at when both tree A results in 0 successes and tree B also results in 0 successes
- Exactly 1 requires tree A to have exactly 1 success, or tree B to have exactly 1 success
- Exactly 2 requires tree A to have exactly 2, tree B to have exactly 2, or both trees to have exactly 1

The pattern here is that we need to permute the first (N - 1) outcomes of tree A with the first (N - 1) outcomes of tree B, for all combinations where A + B is less than our total N that we are seeking.

If you look at the JavaScript code you'll see this being done. Instead of just calculating the probabilities for tree A and tree B, we instead store a table for each tree of what the probability is for *exactly* 0, *exactly* 1, *exactly* 2, etc. and then permute the probabilities for the regular pulls with the probabilities for the bonus pull.

Expected Values

Here's some things to consider when examining expected values:

- You can have odds less than 50% and still have an expected value greater than 0.5. Just because the expected value is greater than 0.5 doesn't mean you're likely to get it, since the game doesn't award you fractions of units and your expected value is still less than one.
- If the odds of you getting at least 1 is greater than 50%, the expected value should be greater than 0.5 but not necessarily 1. You can have a greater than 50% chance of getting a unit and still have an expected value of less than 1, since the game can only award you 0 or 1 units and you are closer to 1 than you are to 0.

If all of this seems confusing and/or contradictory, well, it kind of is. I don't like expected values, I don't think they give you a meaningful representation of odds of success, which is why I hid them behind a link.

Their main use is if you're going for a certain number of units, e.g. you want two 4★ banner units, you can see at what point you (on average) would *expect* to get at least two, regardless of what your actual chances of success at it are. Or if you're going to sink a ton of resources into chasing a 5★ banner unit, you can get an idea of roughly how many 3★ banner units you should expect to get.

• • •

Split Banners

Of all the secret sauces, this might be the most boring one. If you split a banner in two, it halves the odds of getting a specific banner unit on a single pull. Splitting three ways divides the odds in three, etc. For example:
Goal | Normal | Split 2 |

Ticket pull for a 5★ banner unit | 1% | 0.5% |

Bonus crystal for a 5★ banner unit | 3.75% | 1.875% |

So for split banner calculations, all we do is repeat the exact same calculations we do normally but with a different set of odds, chosen based on the number of splits.

Copyright © 2017 by Dan Posluns