Real Random runs away from average zero

StefanL38

Hello,

I was playing around with the real random-object.

I tested if the values summarise to zero if a add them all.
To be able to add something at all I extracted the sign
and then divided the number by bitshifting it to the right.

If I watch the debug-output the summarised value has a tendence
to run away from zero. Where could this come from ?

Am I doing a systematical error in my calculations ?
How must it be changed to get a real BALANCED result that stays around zero ?

Or is this caused by the deterministic behaviuor of the propeller ?

{{ Real Random Test }}

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  
OBJ
  debug : "FullDuplexSerial"
  rr       : "RealRandom"
  

VAR
  long Ptr_2_random
  long WaitTime

  long RandomNr
  long RandomSum

  long LoopCnt

  long PosCnt
  long NegCnt

  long sign

  long DispCnt
  long ModRes
  long TempSum
  
PUB start | i

  'start RealRandom        
  rr.start        

  debug.start(31,30,0,115200)

  LoopCnt   := 0
  RandomNr  := 0
  RandomSum := 0
  RandomSum := 0

  PosCnt    := 0
  NegCnt    := 0
  DispCnt   := 0
  TempSum   := 0
  
  repeat                           
    'RandomNr := long[noparse][[/noparse]Ptr_2_random]
    RandomNr := rr.random
   
    if RandomNr < 0
      sign := - 1
      NegCnt++  
    else
      sign := 1
      PosCnt++  
    
    RandomNr := || RandomNr
    RandomNr := RandomNr >> 15

    TempSum := TempSum + RandomNr 
    RandomSum := RandomSum + (RandomNr * sign)

    LoopCnt++
    if (LoopCnt > 10000) 'or true
      DispCnt++
      debug.str(string("DispCnt="))
      debug.dec(DispCnt)
      debug.tx(32)

      debug.str(string("TempSum="))
      debug.dec(TempSum/10000)
      debug.tx(32)

      debug.dec(RandomSum)
      debug.tx(10)
      debug.tx(13)
      LoopCnt := 0
      TempSum := 0

best regards

Stefan

Post Edited (StefanL38) : 4/7/2009 11:20:36 PM GMT

Phil Pilgrim (PhiPi)

There's no reason to expect that the sum of a length-n series of uniform random variates will converge toward n times the mean. In fact, the standard deviation of the sum increases as the square root of n. That said, the sample means (sum / n) should converge to the mean as n increases.

In other words, divide your sum by your sample size. It should converge to zero as the sample size increases.

BTW, you don't need to go through all those gyrations with the sign bit to get a sum. You can either divide each random number by 65536 or do an arithmetic right shift (~>) to propagate the sign bit right.

-Phil

StefanL38

Hello Phil,

thank you for your post.

A friend of mine uses the random-values similar to the demo.
A wheel is switched ON/OFF to turn right/left for a randomized time
and in this application all ways summarize up with NO dividing
and I would like to have it really randomized even that ALL values summarise to zero.

Could it be that the values are too big and that I hit the 32bit-border ?

But I get similar results with a bigger divider

Does anybody have an explanation for that ?

Could it be improved by changing some parameters about the counters ?

best regards

Stefan

mctrivia

out of curiosity what do you get with the following?

  repeat (x<65536)&&(x>-65536)
    RandomNr := rr.random
    x:=x+RandomNr/1048576
  does this code here ever run?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

Phil Pilgrim (PhiPi)

If the numbers summed to zero every time, they would not be independently random. You will never be able to get RealRandom to behave in this fashion. There are pseudo-random sequences which, over their entire range will sum to zero reliably. But this is only because they are not independent over the long run, their sequences repeating after touching every integer in their range.

Phil

mctrivia

the reason for my code is that if the random numbers are distributed evenly above and below 0 though they will not sum to 0 they will keep within a wide range indefinitely.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

virtuPIC

Well, generating real random numbers doesn't tell anything about their distribution. You can have an average different from zero (as numbers thrown with dice), and you don't know anything about higher order moments (like variance) or correlation. Regarding the real random object I haven't looked at the code this time but I remember that it is built on PLL jitter. In this case I would expect a high autocorrelation caused from periodicity of the jitter.

If you want to produce reasonable, uniformly distributed real random numbers you should use a little external hardware which employs quantum effects. No, I don't mean a radioactive sample with Geiger counter. Would work - but would be rather expensive. But what else? You can simply take a diode or part of transistor give it a high backward voltage and measure the current. There will be noise that is real quantum-random. Or put a camera in the dark and measure the signal.

No matter which mechanism you choose you should perform the usual random quality tests and maybe filter with a de-correlator. Producing good noise is not as easy as it is told to be...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

Toby Seckshund

Here in the uk there was the National saving bonds. There built a quantum type machine to get the randomness using two Zener diodes. This worked for ages but now it is widly notice that if you trade in old numbers and buy new there seem to be a higher payout rate. I wonder what "random number" genny they use now? (M$ ???)

MagIO2

Ehem ... you did not tell us in which direction your sum diverges.

But I guess Phil is right. You can not rely on the fact that randomness will summarize to zero. Because besides short term randomness you also have long term randomness. Maybe after a few hours randomness thinks : OK, and now lets diverge in the opposite direction for a while.

But I see a small chance that the binary number format is causing a deviation as well. Have a look at the number range for a word:
it's from -32768 to 32767. I guess you will see that asymetry in the sum as well.

I'd try this
if RandomNr<0
RandomNr++

In this way your range is now from -32767 to·32767 and you have 2 nullpoints, but that has no effect on the sum.

Post Edited (MagIO2) : 4/8/2009 6:58:51 AM GMT

virtuPIC

BTW, if the statistic distribution of a sample of your random numbers have an average of zero then averaging the numbers won't give zero in most cases. You have to expect a result that deviates more than the standard deviation in about 37% percent of all cases.

MagIO2 said...

I'd try this
if RandomNr<0
RandomNr++

In this way your range is now from -32767 to 32767 and you have 2 nullpoints, but that has no effect on the sum.

...but this changes the distribution! If you use it for cyptography you will get weaker ciphers. If you use it for simulation you will get wrong results.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

MagIO2

Ok, then let's forbid the number 0, it's useless anyway ;o) . After cutting away the upper 16 bits but before applying the sign again we simply say

if RandomNr==0
RandomNr++

Then we have a number range from -32768 to 32768 where every number has the same chance. So the distribution amongst the allowed numbers is equal.

mctrivia

I think you would need a pretty accurate ad converter to measure shot noise in a diode

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

mctrivia

anyone know how accurate an ad would be required? I figure if I mega shield the circuit and keep only the least significant bit I should be able to get very random numbers. I Wish to make a solid state otp key generator

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

virtuPIC

Have a look at www.nanobox.endoftheinternet.org/Download/files/RNG/rng.html. Okay, it's AVR stuff. (May I stay with you anyway? I hope so!) There you also find a schematic where a BE junction of a transistor is used to generate the noise. There is no separate ADC.

Anyway, if you calibrate correctly you only need a single bit ADC - also called a comparator. Sure, then you need some digital filtering. But you have to filter the signal anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

MagIO2

Hi Stefan!

I tried this code:

var
  long rnd
  long sum,num
obj
  rndm: "RealRandom"
  debug: "FullDuplexSerial"
  
pub  MyRandomTest
  rndm.start
  debug.start( 31, 30, 0, 57600 )
  debug.rx
  debug.tx( 0 )
  
  repeat
    rnd:=rndm.random
    num:= rnd & $fff
    if num<$800
      sum+=(num&$7ff)+1
    else
     sum-=num&$7ff
    debug.hex( rnd, 8 )
    debug.str( string( "," ))
    debug.hex( num, 8 )
    debug.str( string( "," ))
    debug.hex( sum, 8 )
    debug.str( string( 13 ))
    waitcnt( clkfreq/5+cnt )

·And I think it really works fine! It ran away from zero as well, stayed somewhere around $10000 for minutes. But then it came back to zero as well. That for me looks like being real real randomness.

cgracey

I see some talk here of using external circuits to get real randomness. The whole point of RealRandom is to achieve this very·thing, but completely within the confines of the Propeller, without any·I/O pins or external components. And it works just fine. The fact that it is internal means that there is no way to deterministically influence it from the outside, which has·added value over an external-component(s) solution.

The issue of real randomness·took me·considerable time and effort·to get my head around, and I'm yet no expert. However, I did get far enough to·learn some empirical and vital things about the nature of real randomness and what is practically required to achieve it in a digital system. I tried to convey this in the header text of the RealRandom object:

---

- Real Random v1.2························· - by Chip Gracey - (C)2007 Parallax, Inc. - 23 March 2007 -

---

-···································································································· -
- This object generates real random numbers by stimulating and tracking CTR PLL jitter. It requires·· -
- one cog and at least 20MHz.········································································ -
-···································································································· -

---

- Background and Detail:············································································· -
-···································································································· -
- In your programming, you might have used 'var?' to generate a pseudo-random sequence, but found the -
- same pattern playing every time you ran your program. You might have then used 'cnt' to 'randomly'· -
- seed the 'var', and as long as you kept downloading to RAM, you saw consistently 'random' results.· -
- Eventually, you downloaded to EEPROM to set your project free, but what happened nearly every time· -
- you powered it up? You were dismayed to discover the same 'random' sequence, over and over. This··· -
- could quickly lead you to wonder, "Where's the end to this madness? And will I ever find true······ -
- randomness?". The problem was this: 'cnt' almost always powers-up with the same value, and you were -
- sampling it at a constant offset, which kept yielding the same number. No amount of clever coding·· -
- can get you out of this kind of trap. What you need is some source of real randomness.············· -
-···································································································· -
- A real random number is impossible to generate within a closed digital system. This is because····· -
- there are no reliably-random states within such a system at power-up, and after power-up, the······ -
- system behaves deterministically. Random values can only be 'earned' by measuring something outside -
- of the digital system.············································································· -
-···································································································· -
- In order to have real random numbers, some physical or analog system rich in uncertainty must be··· -
- monitored. It turns out that we're in luck here, because the Propeller happens to have a host of··· -
- sufficiently-analog subsystems which can be exploited for this purpose -- the cogs' CTR PLLs.······ -
- These can be exercised, to good effect, without any external I/O activity.························· -
-···································································································· -
- This object sets up a cog's CTRA PLL to run at the main clock's frequency. It then uses a pseudo-·· -
- random sequencer to modulate the PLL's target phase. The PLL responds by speeding up and slowing··· -
- down in a an endless effort to lock. This results in very unpredictable frequency jitter which is·· -
- metered by a WAITVID instruction and then fed back into the sequencer to keep the bit salad········ -
- tossing. The final output is a truly-random, 32-bit, unbiased value that is fully updated every···· -
- ~100us, with new bits rotated in every ~3us. This value can be sampled by your application whenever -
- a random number is needed.········································································· -
-···································································································· -

---

Note that the pseudo-random sequencer is fed from the jitter, so no one needs to suppose that a pseudo-random sequence is dictating the CTR's PHS state pattern, resulting in a probable jitter response. The slightest CNT variance (jitter, as measured by WAITVID) is reseeding the sequencer every time·through the loop, causing the sequencer to take radical turns which compound in each loop of the code, sending the sequencer on a mad dash all over the place. I think of it as a garbage disposal with a turbulent flow of debris being forced through it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Philldapill

Chip,
I understand that this "compounding" of randomness is what helps make the result even more random, but is the jitter in the analog circuitry influenced by the outside world still? For example, if you lower the temperature nearly to the non-working point of the chip itself, doesn't this affect the jitter? From the other extreme, can't a hot chip cause more jitter? Granted, the final result will probably not be affected either way.

This whole topic I find interesting. Is there really anything TRUELY random in the universe itself? I mean, this may be a little off topic, but it seems like you can reduce the entire universe into a series of equations, and have everything predicted by them. I know quantum mechanics is supposed to have probability, but couldn't that follow non-probability based laws as well which we just don't understand yet? It seems like the universe itself is a self contained digital system, and we are only probing it's PLL when we think we have found a means of randomness. It's late. I may be rambling, but it's all thought provoking, even in a philosophical sense.

mctrivia

the question has been raised for encryption purpose. is your pll method not effected by noise and complete equal spread in bits

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

cgracey

Philldapill said...
Chip,
I understand that this "compounding" of randomness is what helps make the result even more random, but is the jitter in the analog circuitry influenced by the outside world still? For example, if you lower the temperature nearly to the non-working point of the chip itself, doesn't this affect the jitter? From the other extreme, can't a hot chip cause more jitter? Granted, the final result will probably not be affected either way.

PLL jitter is a phenomenon that is manifoldly affected by just about·everything: subtle·manufacturing differences from chip to chip,·average temperature and dynamic local temperature gradients, average voltage and dynamic noise within and without the PLL's VCO, etc. No two chips are going to do the same thing, and nor will even one chip do the same thing twice over a moderate span of samples. This is something that can be easily positively observed, but could be debated negatively·forever. It would be easier to pose the question: Can anybody observe ANY semblance of repetitive behavior in RealRandom? And remember that this PLL jitter is FORCED, in·a very gross way, so it's not like a PLL quality measurement, with ppm variations. The PLL is in a mad dash all over the place, all the time, and every nuance of its response creates drastic changes in its targeted direction.

This whole topic I find interesting. Is there really anything TRUELY random in the universe itself? I mean, this may be a little off topic, but it seems like you can reduce the entire universe into a series of equations, and have everything predicted by them. I know quantum mechanics is supposed to have probability, but couldn't that follow non-probability based laws as well which we just don't understand yet? It seems like the universe itself is a self contained digital system, and we are only probing it's PLL when we think we have found a means of randomness. It's late. I may be rambling, but it's all thought provoking, even in a philosophical sense.

It's hard not to fall into a pattern of circular thinking on this subject. It took me a while to determine what the practical divider is. I think I found it. Can anyone show otherwise?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

StefanL38

Hello,

@mctrivia: my original question was not for encryption it was for summarize random-values over a REAL long time.
Or expressed another way summarise minimum 10.000.000 +-random-values or even 100.000.000 or 1.000.000.000
and see if the sum to something near zero

@Chip:
for 99,99% of all purposes the real-random-object works VERY GOOD
Which application really needs 1.000.000 +-random-values to summarise to zero ?

But I would be very interested how you explain or what your guess is, that the sum runs away from zero
when summarise 10.000.000 values ?


@Phil:
My opinion about the universe is: everything IS deterministic. But you can't predict it in ALL details.
You would have to watch and measure ALL electrons, photons, protons, even quarks to predict it
But if you start watching an electron you are influencing it. The result will be different from an unwachted electron.

If you could do that you would need a supercomputer and sensors and what do I know else to watch it all
I mean a supercomputer that has several bytes for EVERY SINGLE electron, photon etc. in the WHOLE universe.

Where should you place it ? Outside the universe ?
and how many digits for each value needed in the calculations would be sufficient ? 64 digit?
surely not 6400 digits ? not enough. 2^32 digits ? hm maybe your prediction of what is gonna happen will
go 2 seconds more into the future or only 2 femto-seconds ?
I don't know ! Anyway interesting to think and discuss about things like that.

Maybe we should start another thread in the sandbox about this philosophic discussion

best regards

Stefan

virtuPIC

I like the idea of generating real random bits without extra hardware in the RealRandom object. However, I wonder about the quality. Average and variance can be filtered easily. However, the bit sequence may have some periodicity (auto-correlation).

Real random generators should rely on quantum effects. Thermal noise on a resistor, short noise on a NP-junction, radioactive sample - all valid implementations. Okay, there is also the option of being dependent on uncontrollable external influence. If you shoot a ball in billard and it hits other balls the external influence will be amplified in each collision. The gravity of a single person standing at the table completely determines the direction after the ninth collision.

We have quantum and externally determined randomness. I wonder in which class PLL jitter falls?

Oh, and regarding the philosophical question: There is no determinism in the universe. There is only randomness. However, in dimensions we usually live the probabilities are 'one minus epsilon' with epsilon close to zero which makes them appear like determinism...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

heater

Randomness is indeed fascinating. Pretty much every software engineer I have met who comes to this topic for the first time, and I've worked on a number of systems that relied on it, starts to ponder these deep questions. Even if they are not normally prone to philosophizing.

Phils questions are a case in point and they are part of a philosophical debate that has been going on for centuries regarding determinism, free will, the existence of God etc etc. Generally that debate seems to go around in circles as Chip says.

Last time I read around this the theoretical physicists were still in disagreement about the underlying "randomness" or not of quantum mechanics. As Einstein said "I cannot believe God would play dice with the universe"

The more practical point is "can we know it". Lets assume the universe is giant state machine with some underlying rules governing it's transitions. So then nothing is random. But if it is physically impossible for us to determine the rules of the state machine and/or the exact state at a given time then a lot of things are random enough.

Even more practically, for us software type, one of the best tools we have to check for "randomness" is the Diehard tests www.stat.fsu.edu/pub/diehard/

Chip: Did you ever check RealRandom with Diehard?

Personally I like to just turn the random numbers into pixels on a screen and see if I can detect any weird patterns going on. But don't do that for to long. If you watch enough "snow" on the TV for long enough your brain starts to see things that aren't there (including colour on a black and white TV !)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater

See what I mean, we already have the two opposite views firmly entrenched and expressed as definitely or obviously true:

VirtuPIC - "There is no determinism in the universe. There is only randomness."

StefanL38 - "everything IS deterministic."

I always wondered what trains of logic make peoples minds flip into the "universe is random" or "universe is deterministic" state.
Or is that another random occurrence ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mctrivia

personally I believe it is random but God likes to push the odds

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

cgracey

virtuPIC said...
I like the idea of generating real random bits without extra hardware in the RealRandom object. However, I wonder about the quality. Average and variance can be filtered easily. However, the bit sequence may have some periodicity (auto-correlation). I think you *might* be able to see auto-correlation over short runs of samples (several, perhaps), but that would be disrupted very frequently.

Real random generators should rely on quantum effects. Thermal noise on a resistor, short noise on a NP-junction, radioactive sample - all valid implementations. Okay, there is also the option of being dependent on uncontrollable external influence. If you shoot a ball in billard and it hits other balls the external influence will be amplified in each collision. The gravity of a single person standing at the table completely determines the direction after the ninth collision. This is what I'm trying to tell you guys!!! It is the subtlest of variance that influences the LSBs of the measured PLL jitter. A billionth of degree or a volt will change what happens. Then, at the quantization boundaries, quantum effects can have major influence. Most of the behavior is driven by process, thermal, and voltage variance, but I'm sure there are ample contributions from quantum phenomena, too.

We have quantum and externally determined randomness. I wonder in which class PLL jitter falls?

Oh, and regarding the philosophical question: There is no determinism in the universe. There is only randomness. However, in dimensions we usually live the probabilities are 'one minus epsilon' with epsilon close to zero which makes them appear like determinism... Interesting observation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

cgracey

heater said...


Even more practically, for us software type, one of the best tools we have to check for "randomness" is the Diehard tests www.stat.fsu.edu/pub/diehard/

Chip: Did you ever check RealRandom with Diehard?


No, I have not. I am interested to do so, though. I did notice some slight bias, initially, so·I added the unbiasing algorithm which considers two bits at a time and only outputs one of the bits when the pair is different. After adding that, I did long-term summation tests and I found that while it would wander positively and negatively, it would periodically cross zero after many hours, or even days. So, I was satisfied and figured it was done.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

virtuPIC

Yes Chip, yesterday I read a web page on another real random generator based on PIC: home.comcast.net/~orb/details.html. Here the cap of the ADC's S&H is charged and discharged in pseudo-random order. The 'man aside the table' toggles the LSB of the ADC. Sounds similar to the PLL jitter RNG.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

Dennis Ferron

Regarding the original question, if you need your random numbers' sum to tend to stay around 0, why don't you just apply some kind of tweak to force the sum to tend towards 0? For instance: NextNumber := GeneratedNumber - (RunningTotal / 1000) nudges the number down when the sum is too high, and up when the sum is too low, and the change is proportional to the size of the "error" in your running total, but divided by 1000 to throttle back the nudge's influence.

I don't see why you'd assume the sum of a long series of random numbers tends toward 0 without a *reason* or some kind of *natural force* to PULL them to zero. Without a force, condition, or boundary, what exactly is it that you think makes the sum stay in any kind of range? An analogy: if a blindfolded man walks for eternity in a featureless desert, changing directions randomly at random times, with no landmark to tell him where he is, do you expect at the end of eternity he would be found in the same general area, or be very far from his starting point?

StefanL38

Hello Chip,

first of all your avatar makes me smile from one ear to the other. Fozzy-bear wearing a propeller-hat.
I like this kind of humor.

I like to mix up words.
So you are a "Progreller" (Propeller-programmer) where the word "grell" in german means "very bright light"
and second meaning if something is really neat (as the propeller is) and fozzy-bear is a ProBealler

good to read:

Chip said...

I did long-term summation tests and I found that while it would wander positively and negatively, it would periodically cross zero after many hours, or even days. So, I was satisfied and figured it was done.

My own tests lasted only some hours. If it crosses zero after a long term I think there is enough random in it.
(if a description of "enough" random is senseful)

best regards

Stefan

Post Edited (StefanL38) : 4/10/2009 8:17:23 PM GMT

virtuPIC

Dennis Ferron said...
I don't see why you'd assume the sum of a long series of random numbers tends toward 0 without a *reason* or some kind of *natural force* to PULL them to zero. Without a force, condition, or boundary, what exactly is it that you think makes the sum stay in any kind of range? An analogy: if a blindfolded man walks for eternity in a featureless desert, changing directions randomly at random times, with no landmark to tell him where he is, do you expect at the end of eternity he would be found in the same general area, or be very far from his starting point?

Yes Dennis, that's exactly the point I want to make. I also knew this analogy before this discussion. Let's assume he starts at a pole at the center of the desert. He will get any distance from the pole. However, if you divide his distance from the pole by the time he is struggling around you will get a finite number. Statistically speaking, you will get the standard deviation of his walk. However, you cannot expect that he stays at the pole (at zero).

Gosh, what a thread! Philosophical questions, lessons in statistics, unbelievable stuff... It's fun anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

Leon

Quantum random number generation is the best way to get random numbers:

www.idquantique.com/products/quantis.htm

The units aren't all that expensive at about $600, IIRC.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle