Why does this random pattern generator make an organized pattern over time?

[Dav]

This is more of a math/randomize question I suppose.  I didn't go very far in math, so if someone could explain this to me in a layman way why this occurs, I'll be thanking you.

I am playing around making what I think are random pattern makers, but over time this creates an organized pattern on the screen.  Why is that?

Run this for a little while, and slowly it makes organized stripes on the screen.  Shouldn't it remain a random mess?

- Dav

 

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(600, 600, 32)
2.  
3. RANDOMIZE TIMER
4.  
5. DO
6.     FOR l = 1 TO 1000
7.         x = RND * 600: y = RND * 600: c = RND * 255
8.         LINE (x, y)-(x + 20, y + 20), _RGBA(c, c, c, RND * 1), BF
9.     NEXT
10.     _LIMIT 100
11. LOOP
12.  

[Pete]

Did you try this trick, I think Mark posted awhile back?

x = RND(-TIMER)  * 600: y = RND(-TIMER)  * 600: c = RND(-TIMER)  * 255

As to the why part, no clue.

Pete

[SMcNeill]

Remember:  QB64 doesn’t have any true random numbers.  We get values from a pseudo random formula, and that formula repeats every 16,000,000 cycles or so.

[OldMoses]

Here's a modification that seems to mix it up a bit better. Although I'm sure it's still repeating a sequence as it seems to stop after a while anyway.

Funny thing about this, when I just put the RND in lieu of a,b & d as an intermediary, I get a very different result.

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(600, 600, 32)
2.  
3. RANDOMIZE TIMER
4.  
5. DO
6.     FOR l = 1 TO 1000
7.         RANDOMIZE RND * l
8.         a = RND
9.         b = RND
10.         d = RND
11.         x = a * 600: y = b * 600: c = d * 255
12.         LINE (x, y)-(x + 20, y + 20), _RGBA(c, c, c, RND * 1), BF
13.     NEXT
14.     _LIMIT 100
15. LOOP
16.  
17.  

[SMcNeill]

DIM SHARED Array(1000000) AS _FLOAT





FUNCTION Rand
    STATIC Init, IndexOn
    IF Init = 0 THEN
        Init = -1
        FOR I = 0 TO 1000000
            Array(I) = I / 1000001
        NEXT
    END IF
    IF IndexOn = 0 THEN
         RANDOMIZE TIMER
         FOR I = 0 TO 1000000
               SWAP Array(I), Array (INT(RND * 1000001)
        NEXT
     END IF
     IndexOn = (IndexOn + 1) MOD 1000000
     Rand = Array(IndexOn)
END FUNCTION



Something like the above should make it rather hard to find repeating patterns, as you’re constantly using and then shuffling an array of 1000001 elements.  You might give something similar to it a try, for a different random method.

Note: Not actually tested as I’m on my iPad at Mom’s (thus the lack of being in a code box), but the concept should come across, I’m hoping.

[STxAxTIC]

For once, I *actually* think its the pseudo-generator that is responsible for this. I see enough confusion centered around RND that is *not* this issue, but for once, I actually think so...

Anyway, the shortest answer is to re-seed often, like once per main loop. I added one line of code:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(600, 600, 32)
2.  
3. RANDOMIZE TIMER
4.  
5. DO
6.     FOR l = 1 TO 1000
7.         x = RND * 600: y = RND * 600: c = RND * 255
8.         LINE (x, y)-(x + 20, y + 20), _RGBA(c, c, c, RND * 1), BF
9.     NEXT
10.     RANDOMIZE RND
11.     _LIMIT 100
12. LOOP

[bplus]

How about blanking fading out the old:

Code: QB64: [Select]

1. Screen _NewImage(600, 600, 32)
2.  
3. Randomize Timer
4.  
5. Do
6.     For i = 1 To 1000
7.         x = Rnd * 600: y = Rnd * 600: c = Rnd * 255
8.         Line (x, y)-(x + 20, y + 20), _RGBA(c, c, c, Rnd * 20), BF
9.     Next
10.     Line (0, 0)-(_Width, _Height), &H10000000, BF
11.     _Limit 100
12. Loop
13.  
14.  
15.  

[Dav]

Thank you all for your quick answers and workarounds!  I went to check on my dad a little while, and came back to find several answers.   All of them are helpful.  So I guess it's a visual representation of the random formula, and the best way is avoid a pattern is to re-seed often?  I like how quick a fix RANDOMIZE RND will do it. Thanks.

A while back I was looking for a quick way to do a wind/scrubbing effect for something else, and @bplus your code up there finally got me there. Thanks.

- Dav

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(600, 600, 32)
2.  
3. RANDOMIZE TIMER
4.  
5. DO
6.     FOR i = 1 TO 1000
7.         x = RND * 600: y = RND * 600
8.         LINE (x, y)-(x + RND * 200, y + RND * 20), _RGBA(RND * 255, RND * 255, RND * 255, RND * 20), BF
9.     NEXT
10.     LINE (0, 0)-(_WIDTH, _HEIGHT), &H10000000, BF
11.     _LIMIT 100
12. LOOP
13.  

[Bert22306]

Naw, I think we're going on the wrong track. First off, try to reseed often, within the loop, and the same pattern soon occurs.

The problem has nothing to do with the PRNG. It has everything to do with the fact that Rnd creates numbers in the range 0 to <1. An then, you are adding 20 to that random number.

Well, 20 + Rnd will hardly be all over the map!!

[luke]

Naw, I think we're going on the wrong track. First off, try to reseed often, within the loop, and the same pattern soon occurs.

The problem has nothing to do with the PRNG. It has everything to do with the fact that Rnd creates numbers in the range 0 to <1. An then, you are adding 20 to that random number.

Well, 20 + Rnd will hardly be all over the map!!

I disagree with the answer in its entirety.

Reseeding a random number generator with numbers from that generator is really Not A Good Idea. Keep in mind reseeding merely reads numbers from a different position in the sequence and does not change the order of the sequence, and if you're reseeding with numbers from the generator itself you're really just reading the sequence in a non-linear fashion.

Your options for better randomness are:
 - Implement your own random number generator. Algorithms for such are available on the internet and should be able to give decent performance with not too large an implementation.
 - Ask elsewhere for random numbers. On Linux & Mac OS random numbers can be had by reading the file /dev/urandom. On Windows I believe @SpriggsySpriggs has an API call that provides random numbers.

[Bert22306]

I disagree with the answer in its entirety.

Reseeding a random number generator with numbers from that generator is really Not A Good Idea.

Did you bother to read my response, Luke? I said, do try to reseed, and the same pattern occurs.

Edit: on re-read of Dav's original program, he does multiply Rnd by large numbers initially. But then, adds this constant bias of 20. So my initial response was not quite right, but still, it's not the PRNG causing the problem.

Your options for better randomness are:
 - Implement your own random number generator. Algorithms for such are available on the internet and should be able to give decent performance with not too large an implementation.

And that will not solve the problem, if you continue to add a constant bias of 20, to draw the lines.

I've provided two programs to test the reasonable actual results of the built-in PRNG. It's not that bad, certainly not at drawing random dots of a flat screen. Try it. Works pretty darned well.

Code: [Select]

Rem  Program creates dots using random x and y coordinates
Rem -------
Do
    Call Initialize
    Call DrawDots
Loop
End

Sub Initialize
    _Title "Random Number Distribution"
    Screen _NewImage(840, 480, 12)
    Cls
End Sub

Sub DrawDots
    Randomize Timer
    Color 9
    Print "First random number this cycle"; Rnd
    Do
        x = Rnd * 840
        y = Rnd * 480
        Circle (x, y), 1, 14
        _Delay .005
        If InKey$ = Chr$(27) Then Exit Do
    Loop
    Cls
    Locate 15, 35
    Input "Start with new seed (y/n)"; cont$
    If cont$ = "n" Then End
End Sub


[STxAxTIC]

Not to talk past both you guys, because Luke is right - but if you wanna stay within the vanilla ecosystem, I noticed you can make the patterns go away by just tossing out a few RNDs every time you need one:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(600, 600, 32)
2.  
3. RANDOMIZE TIMER
4.  
5. DO
6.     FOR l = 1 TO 1000
7.         x = rng * 600: y = rng * 600: c = rng * 255
8.         LINE (x, y)-(x + 20, y + 20), _RGBA(c, c, c, rng * 1), BF
9.     NEXT
10.     _LIMIT 100
11. LOOP
12.  
13. FUNCTION rng
14.     FOR k = 1 TO INT(RND * 4)
15.         j = RND
16.     NEXT
17.     rng = RND
18. END FUNCTION

[luke]

It seems I misread your message.

In that case I disagree with the second half of your message.

The limitation of the random number generator is not at all due to it returning a number between 0 and 1. The number is the result of rnd_seed/0x1000000 where rnd_seed is a a 32 bit integer and a SINGLE has 24 bits in just the significand alone (not including the exponent) so there's plenty of bits to hold a good distribution.

And just in case you thought the built-in random number generator was good at putting dots on the screen, here's a program that says otherwise:

Code: [Select]

Screen 12

Do
    x = Rnd * _Width
    y = Rnd * _Height
    c = Rnd * 16
    q = Rnd
    PSet (x, y), c
    _Limit 10000
Loop


[Bert22306]

Weird, you do get a pattern.

But not if you run it modified like this:

Code: [Select]

Screen 12

Do
    x = Rnd * _Width
    y = Rnd * _Height
    Circle (x, y), 1, 15
    Rem     c = Rnd * 16
    Rem     q = Rnd
    Rem     PSet (x, y), c
    _Limit 10000
Loop


[STxAxTIC]

That's not really an apples-to-apples comparison Bert. Here's Luke's program with every instance of RND replaced with "rng". Makes no pattern.

Code: QB64: [Select]

1. SCREEN 12
2.  
3. DO
4.     x = rng * _WIDTH
5.     y = rng * _HEIGHT
6.     c = rng * 16
7.     q = rng
8.     PSET (x, y), c
9.     _LIMIT 10000
10. LOOP
11.  
12. FUNCTION rng
13.     FOR k = 1 TO INT(RND * 4)
14.         j = RND
15.     NEXT
16.     rng = RND
17. END FUNCTION