Is there a variant of the binomial distribution formula that solves for successes instead of probability? I'm a programmer and trying to create a hash function that reliably distributes features over a length of data based on probability and seed. A generative algorithm of this kind would be simple to make but I want to make in the form of a hash so that I can process the data in parallel without intercommunication.
Anyways, I'm not very strong at math but my research led me to the binomial distribution formula

That is almost exactly what I want except that it is sorta inside out. In my hash parameters, I already have the result P(x), I also have n (number of trials) and p (probability of success per trial). What I don't have is x - the number of successes.
So basically, I want to

*

*go to an arbitrary section of the data I have

*get a "random" number for it from a general purpose random hash that takes position and seed as input and outputs a uniformly distributed pseudorandom value

*plug that "random" number in as the result of the binomial distribution formula (P(x)) along with other parameters like the length of the section (n) and probability of success per trial (p

*get the answer - how many of the features that I'm distributing reside in this section of the data that I'm evaluating

PS! I know that this won't work if I use completely arbitrarily distributed section positions and sizes but no need to worry about that, I'm actually sampling them sequentially in the same size chunks with no overlap. Also I'm aware of the performance nightmare that factorials present to modern computers but I have some bit hacks and specifically chosen hyperparameters to take care of that. Also, I know that I can also get the value I'm seeking by just doing n number of random rolls against the probability per trial but this hash needs to go fast and calculating this many pseudorandom hashes per data section is far too slow.
So essentially the question is - is there a version of this cool formula that has x on the left hand side of the equation?
 A: Perhaps what you seek is the negative binomial law, that gives the number of trials you need to obtain $k$ successes.
https://en.wikipedia.org/wiki/Negative_binomial_distribution
A: Addendum added to respond to the comment of Kevin.

The Math can be programmatically manually derived.
You have that
$$p(x) = \binom{n}{x} p^x q^{n-x}. \tag1 $$
This answer assumes that you are looking for the positive integer $x$ that comes closest to satisfying the above constraint.  If that is not the case, then I am out of my depth here.
You also have that $p(x), n,$ and $p$ are known.  This implies that $q = (1-p)$ is also known.  The problem can be attacked by logarithms of base $(10)$, base $(e)$ (i.e. natural logarithms), or any base that you prefer.
This answer will assume that $\log(r)$ refers to the natural logarithm of $(r)$.
Since $p(x), p,$ and $q$ are known, their logarithms are known.
Let $A,B,C$ denote $\log[p(x)], \log(p), \log(q),~$ respectively.
Then taking logs on both sides of (1) above, you have that
$$A = \log\left[\binom{n}{x}\right] + xB + (n-x)C \implies $$
$$A - nc = x(B-C) + \log\left[\binom{n}{x}\right]. \tag2 $$

(2) above can routinely be attacked programmatically, since canned logarithm functions are standard in programming languages (e.g. C, Java, Python).
Consider that
$$\log\left[\binom{n}{x}\right] \tag3$$
equals
$$\log(n) + \log(n-1) + \cdots + \log(n+1-x) \tag4$$
minus
$$\log(x) + \log(x-1) + \cdots + \log(1). \tag5 $$
So, you use the analysis in (3), (4), and (5) above to perform a simple loop of the positive integers.  That is, you have $x$ loop through the elements in $\{0,1,\cdots,n\}$, and choose the value of $(x)$ that comes closest to achieving equality in (2) above.

Edit
Somewhat off-topic to a Math forum.
If I was writing the computer program, I would want to optimize the code.  The cleanest way is to first create an array (or table, if you will) of logarithm values: that is, you would have the key be $k$, and the value be $\log(k)$.  You would do this once, at the start of the program.
Then, as $x$ loops through the integers, instead of repeatedly invoking the canned logarithm function against positive integers, you would perform array (key-value) lookups of information that you have stored in memory.
The approach in the previous two paragraphs may be iffy.  It is good if you are solving more than one equation, with one computer programming run, so you can avoid repeated lookups.  It is bad if $n$ is so large that memory is a premium.  Also, (to a certain extent), if running a program to compute only one solution, it may not be helpful, given the analysis in the following paragraph.
If you take a closer look at the evaluation of
$$\log\left[\binom{n}{x}\right] $$
you will see that as $x$ goes to $x + 1$, it is simply a matter of taking the previous computation, adding $\log(n-x)$ to it, and also deducting $\log(x+1)$.

Addendum
Responding to the comment of Kevin.

I believe OP is looking for an inverse transform sample, which is close to what you describe but should be doable in O(1) time complexity (i.e. no looping) with proper algebra (by inverting the CDF).

I regard his comment as very interesting.  My knowledge in this area is virtually non-existent.  I provided my answer only because I saw what I regarded as a reasonably efficient way of programmatically dealing with $~\displaystyle \log\left[\binom{n}{x}\right].$
If my guess as to how to interpret his comment his correct, this suggests that my entire answer represents an inferior approach.  Given my ignorance in this area, that is certainly plausible.
A: Based on your question, I think you are trying to sample numbers drawn from the binomial distribution, by transforming a uniformly-distributed random number into a number distributed according to the binomial distribution. You are correct to point out that the formula you have is "inside-out" - but in the case of a discrete distribution such as the binomial, you can still use it to get what you want. Here's some pseudocode:
Let P(x) be the probability mass function of the distribution in question
(Note: This is the same P(x) you have in your question.)
Initialize x to -1.
Initialize p to a random (floating-point) number in [0, 1).
(Note: You can use a hash value for p, as long as it is uniformly-distributed.)
(Note: p must be strictly less than 1.0, or the algorithm will not terminate.)
Do:
  Increment x.
  Subtract P(x) from p.
While p > 0.
Return x.

This is suboptimal, because it requires looping over each possible value of x. However, it is extremely general, because you can replace P(x) with any probability mass function, and therefore you can use this algorithm to sample from any discrete distribution. For continuous distributions, you should use inverse transform sampling instead. You can also use inverse transform sampling for discrete distributions, but you will need to do a little bit of algebra to get the inverse CDF, and so this is more complicated than the algorithm shown above. However, inverse transform sampling generally has a time complexity of O(1) instead of O(x), so it should be faster in most cases.
My advice: Start with the algorithm that is simplest to understand, and benchmark your code. If it is fast enough, then don't bother writing up a more complicated algorithm that's harder to understand.
