crepegoat / fehnt Goto Github PK

events probabilities are currently calculated by the type of event (standard, legendary, etc.). However, every one of these summons follows an identical structure that is solely determined by the starting probabilities:

• they operate on probability tiers, which increment every 5 summons after a session ends
• the focus/5-star pool percentages increase cumulatively and uniformly by precisely 0.5% every probability tier
  • "uniformly" -> if 5-star is 2% and 5-star focus is 4%, then the next prob tier they will be 2% * (6.5% / 6%) and 4% * (6.5% / 6%), respectively.
• the other pool percentages decrease cumulatively and uniformly by precisely 0.5% every probability tier

Thus, the derived classes can be removed and replaced with a single class that uses the starting probabilities as a constructor parameter.

Currently results are just "how many units did I get in a given percentage pool?", which does not accurately describe which units were drawn.

Options:

1. also track the number of unique targets pulled

• still doesn't tell you how many of each was pulled (2 unique units, 4 in total -> 2 and 2? 3 and 1?)
• fine for results reporting, but may not give the summoner logic enough information to make decisions correctly (e.g., I drew 2 unique units and I drew those units 22 times, but I only want to stop if I have 11 of each -> do I have 11 and 11? 21 and 1?)

2. track the number of each target pulled

• fixes the main problem, and the problem in option 1
• store sorted counts? s.t. for 2 5-star focus red units, (1, 3) is the same as (3, 1)
  • since the units aren't named this should be accurate without loss of generality
  • reduces the number of unique states to process -> faster computations

Currently when initiating a new session, the program branches into a unique session state for every possible combination of stone quantity (e.g., 3 red 1 blue 1 green 0 gray), of which there are precisely 56. However, many of these can be lumped together w/o loss of generality, based on the summoner's actions. (E.g., how many blue/green/gray stones there are doesn't affect the summoner's decision, if the summoner is only interested in summoning red; in this case, the (4 red 1 blue) state can be lumped together w/ the (4 red 1 green) and (4 red 1 gray) states.)

Reducing the number of branches should greatly increase computation speed, esp. for larger orb counts.

the results from this program are poorly legible in their current form. it would be ideal to generate a visual plot describing the results.

inputs are currently hard-coded in runner.py. change to accept inputs externally, either from file or CL.

numpy is fast when it is allowed to work on bulk amounts of c-typed data simultaneously. However, this application uses no c-typed data whatsoever, and in some cases involves smaller array sizes (~4-5 elements). Because of this, it may be faster (particularly in jit-compiled situations like on pypy) to have a pure-python version of numpy instead, that merely provides the syntactical convenience of the package w/o the C-extensions.

Note - this should be verified with profiling.

The other option is to remove static_frame entirely, and just perform all data manipulations manually.

instead of asking users to populate event information manually, this should be available automatically from an internet source.

Currently the program starts with a known orb count and iterates through states of remaining orbs down to zero.

The code can be rewritten to:

• iterate over orbs spent; start from 0 and iterate upwards
• aggregate results (%-chance of x targets pulled, (for finite targets) avg. orbs spent) on every orbs-spent milestone and yield them