Does True Randomness Actually Exist? ( ^&*#^%$&#% )

Sort:
llama36
Optimissed wrote:

PDF? Pls don't assume I know what pls means.

PDF is probability density function.

When you take the integral of the PDF, you get the CDF or cumulative distribution function.

If a distribution is continuous, then there are infinitely many values it can take.

When you have a CDF equation, and you plug in a number, it will tell you the probability of getting that number or less. For example plugging in 5, it will tell you the probability of getting 5 or less. For the exact value of 5 (or any exact value), it will tell you the probability is zero.

llama36
Mike_Kalish wrote:

@4206

the probability of any specific result is zero

 

Question:  When you are talking about an infinite serious, what is meant by a "specific result"?

For example if the experiment is to flip a coin 2 times, there are 4 individual results:

HH
HT
TH
TT

You could ask the question "what is the probability of getting at least one H?"
or
"What is the probability of getting the result HT?"

 

When there are infinitely many results, it's not useful to ask questions like the 2nd (an exact result). You ask questions like the first one (where the answer is a collection of results, in this case 3 have at least one H, so the probability is 0.75).

DiogenesDue
llama36 wrote:

Oh, if time is the problem, there may be tricks to speed it up. Everything in the computer is 1s and 0s, so it works with them very quickly. Just pretend 1s are heads and 0s are tails (or the other way around).

Then you can use simple operations like AND and bit shifting, which computers do very quickly.

For for example you do the AND function for two bits. If it returns 1 then you know they're the same. If it returns zero you know they're different. Then you shift to the next bit and do it again. (lol, 0 and 0 outputs zero, but still... use XOR same idea).

When the answer is zero, just pretend they "cancel out" and when the answer is 1, increment a counter. What you'll be left with is the counter shows the "extra" heads or tails. Add half of your starting number to the "extra" for heads, and subtract "extra" from half the starting number for tails (or vice versa).

I've never tried this with python, but I assume it's possible. You can also start experimenting with C++ for example. Once you can do one language it's pretty easy to try some of the same things in a new one. Python tends to be slower which is why I mention it.

Python is slow for such applications...it's an interpreted language, not compiled.  Some Python developers will try to claim it is compiled *and* interpreted, because Python has a runtime "compiler" that takes the interpreted bytecode and runs it in the Python virtual machine, but since it actually interprets the code each time it is run, it is an interpreted language, and the step of interpreting the code is just wasted cycles vs. a compiled executable.

Compiled executables are themselves somewhat inefficient, but very few people write Assembly Language code anymore, so a good compiler is about as fast as you are going to get.

The app itself is simple.  You could write a coin flip app in a batch file wink.png, but that would also be incredibly slow.

Mike_Kalish
llama36 wrote:
Mike_Kalish wrote:

@4206

the probability of any specific result is zero

 

Question:  When you are talking about an infinite serious, what is meant by a "specific result"?

For example if the experiment is to flip a coin 2 times, there are 4 individual results:

HH
HT
TH
TT

You could ask the question "what is the probability of getting at least one H?"
or
"What is the probability of getting the result HT?"

 

When there are infinitely many results, it's not useful to ask questions like the 2nd (an exact result). You ask questions like the first one (where the answer is a collection of results, in this case 3 have at least one H, so the probability is 0.75).

The reason I asked the question is that Elroch made reference to that in Quote 4206, so I was actually asking Elroch.

llama36
Mike_Kalish wrote:
llama36 wrote:
Mike_Kalish wrote:

@4206

the probability of any specific result is zero

 

Question:  When you are talking about an infinite serious, what is meant by a "specific result"?

For example if the experiment is to flip a coin 2 times, there are 4 individual results:

HH
HT
TH
TT

You could ask the question "what is the probability of getting at least one H?"
or
"What is the probability of getting the result HT?"

 

When there are infinitely many results, it's not useful to ask questions like the 2nd (an exact result). You ask questions like the first one (where the answer is a collection of results, in this case 3 have at least one H, so the probability is 0.75).

The reason I asked the question is that Elroch made reference to that in Quote 4206, so I was actually asking Elroch.

I apologize, I didn't check the number.

llama36
btickler wrote:
llama36 wrote:

Oh, if time is the problem, there may be tricks to speed it up. Everything in the computer is 1s and 0s, so it works with them very quickly. Just pretend 1s are heads and 0s are tails (or the other way around).

Then you can use simple operations like AND and bit shifting, which computers do very quickly.

For for example you do the AND function for two bits. If it returns 1 then you know they're the same. If it returns zero you know they're different. Then you shift to the next bit and do it again. (lol, 0 and 0 outputs zero, but still... use XOR same idea).

When the answer is zero, just pretend they "cancel out" and when the answer is 1, increment a counter. What you'll be left with is the counter shows the "extra" heads or tails. Add half of your starting number to the "extra" for heads, and subtract "extra" from half the starting number for tails (or vice versa).

I've never tried this with python, but I assume it's possible. You can also start experimenting with C++ for example. Once you can do one language it's pretty easy to try some of the same things in a new one. Python tends to be slower which is why I mention it.

Python is slow for such applications...it's an interpreted language, not compiled.  Some Python developers will try to claim it is compiled *and* interpreted, because Python has a runtime "compiler" that takes the interpreted bytecode and runs it in the Python virtual machine, but since it actually interprets the code each time it is run, it is an interpreted language, and the step of interpreting the code is just wasted cycles vs. a compiled executable.

Compiled executables are themselves somewhat inefficient, but very few people write Assembly Language code anymore, so a good compiler is about as fast as you are going to get.

The app itself is simple.  You could write a coin flip app in a batch file , but that would also be incredibly slow.

Oh, so python is simply bad for such things, ok.

KingDoomYTX
Uhm True randomness does not exist if you look into the future. Everything is already determined.
llama36
Optimissed wrote:

Yes thanks, Llama. I remember now learning that at school. I enjoyed maths but the teacher wasn't great and I never got past second order differential equations and lost interest. I dropped out of a Mech. Eng degree because I was bored with maths. My son seemed to be a mediocre mathematician at best and I motivated him to believe he could be really good if he thought of nothing else for about a year and a half and he ended up getting a first class MMath and went on to physics. I was more good at mental arithmetic than maths. That meant I could score extremely high in things like IQ tests, due to concentration, photographic memory and visualisation skills as well as the ability to see the way to do puzzles very easily and basically invent things. That was no use whatsoever in academia but it was very useful in real life. I can sometimes work out tricky problems extremely fast and accurately, if I'm in the mood. It led to laziness and complacency because I can get myself out of a deep hole by applying myself. Not great either for working for other people. OK for working for myself. I've been very lucky and I am sure we make our own luck, really just by believing and having faith. I'm an atheist. I suppose I ought to mention that.

Ok happy.png

DiogenesDue
llama36 wrote:

Oh, so python is simply bad for such things, ok.

Python, Ruby on Rails, Javascript, PHP, etc.  Yep.  I mean it's okay for a proof of concept as done here, but maybe just do smaller sample sizes.

llama36
KingDoomYTX wrote:
Uhm True randomness does not exist if you look into the future. Everything is already determined.

True randomness does exist, and somewhat astonishingly, you can dig into the quantum physics that underpins it with a simple and cheap experiment.

https://www.youtube.com/watch?v=zcqZHYo7ONs&ab_channel=minutephysics

llama36
Optimissed wrote:
llama36 wrote:
KingDoomYTX wrote:
Uhm True randomness does not exist if you look into the future. Everything is already determined.

True randomness does exist, and somewhat astonishingly, you can dig into the quantum physics that underpins it with a simple and cheap experiment.

https://www.youtube.com/watch?v=zcqZHYo7ONs&ab_channel=minutephysics

That was superb. I've hardly ever before watched an online video and wished it was a little slower. I usually get bored out of my skull and turn it off after two minutes, before I start getting annoyed at the American accents, because most American videos go too slow and that's just rubbing the insult in. I'm going to watch it again, about twice and it should all sink in.

Yes!

This is one of the few videos where I feel like they're talking a bit fast. Usually I have to speed videos up, but this one was already fast, and certain parts needed rewinding.

I'm not sure why they did it this way. I wonder if they were trying to get the video down to a certain time.

Uke8

@elroch, maybe you want to explain them that bell disproved Only local hidden variables proposed by Einstein, and by no mean disprove determinism? I'm not too hot about a thread of misinformation under my skirt.

Thee_Ghostess_Lola

100MM flips in Python 3.6 and a hypo-laptop...

Trial #1:

Counter ({'Heads': 49654953, 'Tails': 49654953})     the last time it reached parity...

Counter ({'Tails': 50000079, 'Heads: 49999921})

368 seconds 

Trial #2:

Counter ({'Heads': 35353526, 'Tails': 35353526})     the last time it reached parity...     

Counter ({'Heads': 50001425, 'Tails': 49998575)

358 seconds

Trial #3:

Counter ({'Heads': 1074648, 'Tails': 1074648})     the last time it reached parity...

Counter ({'Tails': 50002916, 'Heads: 49997084})

378 seconds 

 

the first trial was crazy close & the second one was really close. i have found most trials to be aberrating closer to 1/25000 or 4000 per 100MM so these (3) turned out pretty good happy.png .

Elroch
llama36 wrote:
btickler wrote:
llama36 wrote:

Oh, if time is the problem, there may be tricks to speed it up. Everything in the computer is 1s and 0s, so it works with them very quickly. Just pretend 1s are heads and 0s are tails (or the other way around).

Then you can use simple operations like AND and bit shifting, which computers do very quickly.

For for example you do the AND function for two bits. If it returns 1 then you know they're the same. If it returns zero you know they're different. Then you shift to the next bit and do it again. (lol, 0 and 0 outputs zero, but still... use XOR same idea).

When the answer is zero, just pretend they "cancel out" and when the answer is 1, increment a counter. What you'll be left with is the counter shows the "extra" heads or tails. Add half of your starting number to the "extra" for heads, and subtract "extra" from half the starting number for tails (or vice versa).

I've never tried this with python, but I assume it's possible. You can also start experimenting with C++ for example. Once you can do one language it's pretty easy to try some of the same things in a new one. Python tends to be slower which is why I mention it.

Python is slow for such applications...it's an interpreted language, not compiled.  Some Python developers will try to claim it is compiled *and* interpreted, because Python has a runtime "compiler" that takes the interpreted bytecode and runs it in the Python virtual machine, but since it actually interprets the code each time it is run, it is an interpreted language, and the step of interpreting the code is just wasted cycles vs. a compiled executable.

Compiled executables are themselves somewhat inefficient, but very few people write Assembly Language code anymore, so a good compiler is about as fast as you are going to get.

The app itself is simple.  You could write a coin flip app in a batch file , but that would also be incredibly slow.

Oh, so python is simply bad for such things, ok.

Not really. Python is (fairly) slow for sequential operations. However, vectorising your code using numpy means it is quite fast.

For example, tossing a million coins a hundred times, and print out the difference between the number of heads and the number of tails in each of the 100 trials.

This code takes just over half a second.

import numpy as np
from time import time

start = time()
x = np.random.randint(2, size=(1000000,100))
diffs = 2*np.sum(x, axis=0)-1000000
print(means)

print("That took", time()-start, "seconds")

Having noticed Ghostess post above, here is the vectorised way to do that once, also taking about half a second.

import numpy as np
from time import time

start = time()
x = np.random.randint(2, size=100000000)
diff = 2*np.sum(x)-len(x)
print("Surplus heads =", diff,"taking", time()-start, "seconds")

Elroch

Regarding Bell's experiment (and the video), one way to think of it is that the experiment is virtually like being able to take two independent measurements on the same particle without one affecting the result of the other. The reason this is so is that we know empirically that if you make the same observation of both of the entangled particles, you always get the same result, so you kind of get the result for the second particle for free when you observe one of them.

The video leads to this concept by starting by making multiple sequential measurements on the same particle first.

Here is another way to follow the reasoning.

Given that if the filters are 22.5 degrees different you get the same outcome 85% of the time, if the results were deterministic you would get the same outcome at least 70% of the time at 45 degrees (no more than 15% discrepancy twice), and would agree at least 40% (no more than 30% discrepancy twice) of the time at 90 degrees different.  But we know they NEVER agree when 90 degrees different!

Uke8

@elroch, I was hopping that you'll expend on the issue of locality, and determinism, as related to Bell. objectively of course.  

Uke8

Is there a real  QM philosopher that is willing to jump into this muddy water and take the time to explain the topic of determinism honestly and objectively?  

Thee_Ghostess_Lola

pythons got achd issues. attn-centric hypo-active.

heres my code (1BB tries) w/ a eggtimer and a callout list when loopcounts when h-t equal one other:

****

from collections import Counter
import random
import time

coinside = ["Heads","Tails"]
loopy = Counter()
start = time.time()

for _ in range (1000000000):
    
    toss_it = random.choice(coinside)
    loopy [toss_it] +=1

    if loopy["Heads"] == loopy["Tails"]:
        print(loopy)  
                        
print(loopy)

print(f'{(round(time.time()-start))} seconds')

***

Elroch

We have plenty of natural philosophers here. happy.png

Elroch
Optimissed wrote:
 

It will make more sense to me after I've watched it another twice, if I get round to doing that. The problem, slight though it is, is that there could be a deterministic mechanism which gives the appearance that determinism has been disproven through polarisation experiments.

The scientific conclusion is that for the particles to conspire to reproduce the statistics (rather than behaving independently in absolutely any way), it would be necessary for the particle pair to communicate with each other at faster than the speed of light. While the particle pair possesses non-local quantum information, this information does not determine the results of observations, merely the statistics of those observations, a crucial difference - the one between determinism and the real world.

This conclusion is achieved by choosing the direction of the measurements at each location in a way that is unknown at the other at the time of measurements.

Einstein's initial position was that the result predicted by quantum mechanics was so absurd that an experiment would prove quantum mechanics wrong.