random systems
Posted: Tue Oct 15, 2013 12:08 am
From time to time I wonder about so called "random systems" and their level of non/randomness. We call "random" what we can't predict or narrow (sometimes it's due to complexity, sometimes due to lack of it). But can we narrow the non-randomness in so called "random systems"?
Here is a thought. Let say that you have a soup. The soup is made of flavored water and tiny tiny pieces of macaroni, so tiny, that the soup looks like a uniform mass. But "macaroni" = granulation and repeatable patterns in that mass. So now the questions. Let say that we have specific type of noise; matrixes that are made of segments - segments made of smaller sets - sets made of unique samples - samples that have values in certain range.
Can we determine whether in that noise - are there so called "short patterns"? A tiny tiny macaroni pieces? These short patterns would be made of few samples per set or samples that are connected between/through few segments.
Are there "shapes" of these patterns to seek for (like in wavelet comparisons?), or can be they generated somehow from the noise? What are the shapes of these tiny tiny macaroni pieces?
How to determine how big (how many samples) these patters would be? How long are these tiny tiny macaroni pieces
Can we determine the density of short patterns in the noise? How many tiny tiny macaroni pieces are in the soup per plate?
And final question - can we determine which samples in current sampleset are involved in these short patterns, and can we predict what next samples (values) might refer to these samples (or surrounding holes)?
These questions are related to measurement of local non-randomnes in random pattern. They should help to determine whether the noise is random or pseudorandom, or to be more precise - whether in noise there are patterns/attractors/regularities or local fluctuations, that are not shown by classic gaussian probability.
pufff... any examples in FS?
p.s.: just a short note - ruby random generator seems to be less random than FS/SM based one. It produces more numbers of certain kind. I suspect this is because there are less real-time-dependent triggers within the process of generation. But I don't want to measure ruby here; ruby generator just made me to ask such questions.
Here is a thought. Let say that you have a soup. The soup is made of flavored water and tiny tiny pieces of macaroni, so tiny, that the soup looks like a uniform mass. But "macaroni" = granulation and repeatable patterns in that mass. So now the questions. Let say that we have specific type of noise; matrixes that are made of segments - segments made of smaller sets - sets made of unique samples - samples that have values in certain range.
Can we determine whether in that noise - are there so called "short patterns"? A tiny tiny macaroni pieces? These short patterns would be made of few samples per set or samples that are connected between/through few segments.
Are there "shapes" of these patterns to seek for (like in wavelet comparisons?), or can be they generated somehow from the noise? What are the shapes of these tiny tiny macaroni pieces?
How to determine how big (how many samples) these patters would be? How long are these tiny tiny macaroni pieces
Can we determine the density of short patterns in the noise? How many tiny tiny macaroni pieces are in the soup per plate?
And final question - can we determine which samples in current sampleset are involved in these short patterns, and can we predict what next samples (values) might refer to these samples (or surrounding holes)?
These questions are related to measurement of local non-randomnes in random pattern. They should help to determine whether the noise is random or pseudorandom, or to be more precise - whether in noise there are patterns/attractors/regularities or local fluctuations, that are not shown by classic gaussian probability.
pufff... any examples in FS?
p.s.: just a short note - ruby random generator seems to be less random than FS/SM based one. It produces more numbers of certain kind. I suspect this is because there are less real-time-dependent triggers within the process of generation. But I don't want to measure ruby here; ruby generator just made me to ask such questions.