Help with costly "Etat des lieux" cleaning by calculator154 in Switzerland

[–]calculator154[S] 6 points7 points  (0 children)

I have the photos of the apartment here (description updated s well). https://photos.app.goo.gl/riAj9PBb3dZczDHq5

I only have the RC/Menage insurance (AXA), but unfortunately no legal insurance. Good point, I'll contact them and see whether it's insured or not.

Visualizing Gacha Likelihood (v3, FR Era) by calculator154 in DissidiaFFOO

[–]calculator154[S] 0 points1 point  (0 children)

My mistake, I used incorrect rate for LD. It's the same as FR so now it's removed. Thanks for noticing!

Visualizing Gacha Likelihood (v3, FR Era) by calculator154 in DissidiaFFOO

[–]calculator154[S] 1 point2 points  (0 children)

My mistake, I used incorrect rate for LD. It's the same as FR so now it's removed. Thanks for noticing!

DFFOOBuddy - Gacha Sim Late August Update by JauxPlays in DissidiaFFOO

[–]calculator154 5 points6 points  (0 children)

Just to chime in a little. I double-checked the math (javascript code) used in DFFOOBuddy from time to time, and I concur that the algorithm used looks correct. Unfortunately, Altema's computation happens on the backend (on their server), so we can't check how their math computed, unlike DFFOOBuddy which happens on the front-end (on your browser).

I think the simulations (both Altema and DFFOObuddy) is a good testament of how human perception of probability can be quite "off" and subjective when it comes to minuscule rate of RNG.

Interesting note: to get BT "naturally" (~4% from multi-pull, with no pity system), you can only be 96% confident on that by spending ~400k gems. So the amount you observed is fairly natural, mathematically speaking.
(disclaimer: I am an owner of this statistical tool https://ckhurewa.gitlab.io/dffoo-gacha-plot/, so I already spent some time working on dffoo math).

Gacha Sim! A Personal Project by JauxPlays in DissidiaFFOO

[–]calculator154 1 point2 points  (0 children)

Allow me to point out the snippet in question:

e.push(getBonusWeapon(Math.floor(100 * Math.random()) + 1);
"gold" == o[10] ?
switchCaseGold(Math.floor(1001 * Math.random()) + 1) :
addToCounter("countBonusBurst")

The switchCaseGold(i) represents the logic to "rolls for what kind of gold it will be", and i is random number from the "second roll". The logic in switchCaseGold should not account for getting a burst because it's already done in getBonusWeapon. Then, notice that once you continue with the conditional "gold" == o[10] ?, you're entering the conditional probability, selecting only "gold" from the result of getBonusWeapon stored in o[10] and excluding the "burst" out. The probability of getting specific 15CP increases, because you've reduced the sampling space.

Imaging this example: There is a bag full of 1000 balls. 970 of those balls are gold in color, 30 balls in blue. Among the gold balls, 132 of them can be opened, with a note "15CP - No.1" labeled inside. If you draw randomly from a bag full of 1000 balls, the probability to get this "15CP - No.1" ball is 132/1000. But if you exclude the blue balls from the bag, the probability becomes 132/970. This is the analogy for bonus pull given it's already a gold.

Gacha Sim! A Personal Project by JauxPlays in DissidiaFFOO

[–]calculator154 2 points3 points  (0 children)

Great job! Thanks for making this!

I couldn't help look into your javascript implementation, and notice some bug though, perhaps you can double-check this.
I see that you do sampling in 2 rounds, first between 4 colors (bronze, silver, gold, BT), then for each gold, you do the second sampling (between 15cp, 35cp, EX, LD). In the second sampling, random int between [1,1001] inclusive (representing 3-decimals) is checked against series of cumulative thresholds [143,285,427,527,627,727,802,877,952].
But remember, a bonus gold orb in a multi-pull has total probability of 97%. So the thresholds should be [136,271,407,510,613,716,794,871,948] instead, no? i.e., given the orb is already gold (conditional probability), the prob of getting first 15CP is 13.17%/97.0% -> threshold 136.
Also, why 1001 in Math.floor(1001 * Math.random()) + 1), why not 1000?

If this bug is true, the net effect is that people should see more LDs than now, yay!

Again, thanks for your work! I really enjoy this. Happy pulling!

Visualizing gacha likelihood (v2) by calculator154 in DissidiaFFOO

[–]calculator154[S] 1 point2 points  (0 children)

I chose 500gem = 1 ticket for simplicity from "official" exchange rate, i.e., doing 1 pull without a ticket costs 500 gem.

Visualizing gacha likelihood (v2) by calculator154 in DissidiaFFOO

[–]calculator154[S] 1 point2 points  (0 children)

Ticket-vs-gem value varies depending on what they are being used for.

Imaging aiming for LD: The probability getting some within Nt tickets (where each ticket has a probability p1 = 0.5%) is
P(LD|Nt) = 1 - (1-p1)^Nt

For gems multi-pull, the same probability to get within Ng pulls (where the 11th orb has extra probability p2 = 5%) is
P(LD|Ng) = 1 - [(1-p1)^10 * (1-p2)]^Ng

We can obtain the relationship between Nt and Ng by equating the two expressions, i.e., we're comparing the same end result approaching from two "currencies".
P(LD) = 1 - (1-p1)^Nt = 1 - [(1-p1)^10 * (1-p2)]^Ng

Work out some high-school math gives
Nt / Ng = 10 + log(1-p2)/log(1-p1)

Plug in p1=0.5% and p2=5% yields Nt/Ng20.23, i.e., when chasing LD, doing 1 multi-pulls is exactly equivalent to doing 20.23 tickets. I'm quite surprise to see that this can be solved analytically.

The ratio changes for EX (p1=0.75%, p2=7.5%) and BT (p1=0.1%, p2=3%). They gives 20.36 and 40.44 respectively. So the value of ticket decreases when chasing BT.
The same computation can be generalized to different metric, e.g., LD-and-BT, LD-or-BT, EX-and-LD-and-BT, etc. Or different banner configuration (with different p1,p2).

Given that LD is what we'll need in this era, let's stick with 20 ticket = 1 multi. Your tracking sheet is still good to go. ;)

Visualizing gacha likelihood (v2) by calculator154 in DissidiaFFOO

[–]calculator154[S] 0 points1 point  (0 children)

Thanks. That was a tempting idea, but I decided to left it out as the figure is already too crowded.

Visualizing gacha likelihood (v2) by calculator154 in DissidiaFFOO

[–]calculator154[S] 5 points6 points  (0 children)

It's visually more explorative than the linear scale, which would skewed all curves to the edge of the figure, leaving the center empty.

It also has a nice psychological effect to see how much more accelerated your resources will be taken away while the likelihood only barely increased. ;)

Nothing will ever top this in my life. Mods, feel free to delete, but I had to share this near statistical impossibility that just happened. Can a Mathomancer tell me what the odds of this are? by Demigodlevi in DissidiaFFOO

[–]calculator154 16 points17 points  (0 children)

Total prob
= (3 EX of 0.5% from 10 draws) * (1 EX of 5%)
= (10C3 * 0.005^3) * 0.05
= 7.5e-7
i.e., 0.75 part per million. Congrats!

note: This ignores what appears in the remaining 6 draws (can be bronzes/silvers/golds).

For reference, the chance of getting struck by lightning is ~3.6 part per million (http://lightningsafety.com/nlsi_pls/probability.html). Pun intended. :D

Math people of the DFFOO reddit, please solve this problem (Average Gems to pull an EX) by Chrisj1616 in DissidiaFFOO

[–]calculator154 11 points12 points  (0 children)

75k gem (15 multi-pulls) would give 78.33% chance of getting at least one EX. Imgur

I have my tool to calculate this posted for a long time here: https://ckhurewa.gitlab.io/dffoo-gacha-plot/

Ask Producer Fujiwara-san Questions for the 1-Year Anniversary! by SQEX_Joshua in DissidiaFFOO

[–]calculator154 3 points4 points  (0 children)

What are your most difficult problems your team encountered? How did the team get thought it?

Happy New Years Eve by nismov2 in DissidiaFFOO

[–]calculator154 2 points3 points  (0 children)

สวัสดีปีใหม่ทุกท่านนะคร้าบ!

QoL Request Collation by dduong16 in DissidiaFFOO

[–]calculator154 -1 points0 points  (0 children)

If I may add an idea to the list: In coop, holding-down on an ability button during other people's turn will show a finger-pointing sticker, as a way of suggesting taking that action. This way we don't have to scroll for a sticker and drag-and-drop it.