To calculate these probabilities use:
if k > 0 and n != k
n = 100
k = 42
p = 0.52
prob = binom(n, k)*p**k*(1-p)**(n-k)
This gives the probability that you will get 42 1s in 100 tries if the propability for a 1 is 0.52. In order to know the probability getting more than 42, you will need to sum up all the probabilities for k=43…100:
if k > 0 and n != k
n = 100
p = 0.52
prob = 0
(43..100).each do |k|
prob += binom(n, k)*p**k*(1-p)**(n-k)
Sorry I wasn’t clear! I thought my code explained itself. I counted the number of streaks (where a “streak”/“chain” is 100 consecutive sets of 25 flips) out of a million that fulfill your condition (60% of 25 flips returning true). The “result” is the number of such streaks.
I don’t remember my probability and stats, so my idiosyncratic terms and methods may not be of much help. I hope you do get to the bottom of this. I’m interested in the results.
Just wanted to add to this thread to say that Sonic Pi’s randomisation system was never designed to be completely evenly distributed over time. We simply found a 10s white noise audio sample and used that as a lookup table. There’s definitely no guarantees about eventual distribution values.
However, we do now have other random look-up tables to use via
use_random_source (there are currently the following options:
If you think there’s room and value for another source that more specifically fits your needs and would like to contribute one, then that would be fab!
Great! I didn’t know about changing random sources that way.
I really don’t know how it compares technically to the current options, but I wonder if somehow cutting and pasting from this one time pad generator would create useful lookup tables the user could paste into their code.
The purpose of a OTP generator usually is to share the same random numbers between different parties. Not sure why you want to have this feature inside Sonic Pi?
If you just want to have an explicit list of random numbers, this can be generated on any computer system. In Sonic Pi you would use
rrand_i inside a loop and store the numbers in a list. Then the content of the list can be stored in a file on the disk, edited if required, and read again when needed.
By “cutting and pasting from” that web site, I meant to say to use content generated there as a lookup table in a SPI program as an alternative to the tables SPI produces. I didn’t mean cutting and pasting to suggest creating a OTP function inside SPI.
I should point out that this would essentially take the existing list of ‘pre-rolled’ random values and use it to create another. This is why it would produce the same values every time. This approach will not guarantee a fair distribution of choices and also won’t contain the works of Shakespeare if you keep rolling the dice - the random number stream is finite and repeats (after about ~441000 values).
It’s important to state that the goal of Sonic Pi’s random system wasn’t to generate a “properly random” system in a mathematical sense. Instead it was to generate something that felt random enough but was deterministic
If cutting and pasting a lookup table produces a random list with the specific properties you’re looking for, then that might work, yes.
However, it might be the case that you want to be more “careful” in generating a list. Perhaps you might take one of these lists, evaluate it against your requirements, and then tweak it until it exactly matches the distributions you’re looking for. For example, I can imagine a random list that when used to choose a random element from the list n times
[-1, 1] would choose 50%
-1 and 50%
1. I can imagine other distribution styles too.
I remember watching one of the Apple keynotes from quite a few years ago when Steve Jobs was talking about the random functionality in iTunes - Apple’s music software. People had complained that it wasn’t really random enough as they often got multiple songs from the same artists in succession. It was actually being random in the same way you can roll a 1 on a dice a few times in a row. To “fix” this Apple actually reduced the randomness in the true mathematical sense by introducing constraints to stop it being perceived as “not random enough”. By making the system less random people thought it was more random.
I think the thing here is to be clear about what exact requirements you have about the random system, and see if we can find a way of bending the current system in such a way that it behaves close enough to what you need
I fully understand that. My assumption was that @blipson wanted to have an explicit list of random numbers that is editable/changeable and therefore can have any distribution of numbers needed. This is how I would approach it if a special sequence of let’s say -1, 1 with specific properties is needed.
Just to reiterate, I think I’m well covered here. Being music, you just go with what sounds good, and my first approach—if just for convenience’s sake—will be to mess with my Markov matrices rather than the randomness functions, notating the ones that suit me one way or another. That will tie my matrices to Sonic Pi’s random tables, but that hardly matters. If another live coding system comes along, I’m sure I’d be happy tweaking new Markov matrices, like sitting down at a new synthesizer and messing with it.