RND breadth

[MrSwiss]

You'll just have to realize, that it in fact does, nothing to be fixed, therefore.

Btw. the max. value of ULongInt = 2 ^ 64 - 1 or,
ULongInt = &hFFFFFFFFFFFFFFFF

[albert]

@MrSwiss

It doesn't even hardly , get any values below ( 2 ^ 56 )

Code: Select all

screen 19

dim as integer v1 = 0
dim as integer v2 = 0

dim as double n = 0
for a as longint = 1 to 1000000
    
    n = rnd * (2^63)
    n = int(n)
    
    if n > (2^56) then v1+=1
    if n < (2^56) then v2+=1
    
next

print " > ( 2 ^ 56 ) = " ; v1
print " < ( 2 ^ 56 ) = " ; v2

sleep
end

Only the FB coders can fix the problem....

[albert]

Here's RND all by itself , no INT( RND * ?? ) , it gets all the values almost an even number of times.

So the problem is in the INT() function...

Code: Select all

screen 19

do
    
    dim as integer v1 = 0
    dim as integer v2 = 0
    dim as integer v3 = 0
    dim as integer v4 = 0
    dim as integer v5 = 0
    dim as integer v6 = 0
    dim as integer v7 = 0
    dim as integer v8 = 0
    dim as integer v9 = 0
    dim as integer v10 = 0
    
    dim as double n = 0
    
    randomize
        
    for a as longint = 1 to 1000000
        
        n = rnd
        
        if n >=   0 and n <= .10 then v1+=1
        if n >= .11 and n <= .20 then v2+=1
        if n >= .21 and n <= .30 then v3+=1
        if n >= .31 and n <= .40 then v4+=1
        if n >= .41 and n <= .50 then v5+=1
        if n >= .51 and n <= .60 then v6+=1
        if n >= .61 and n <= .70 then v7+=1
        if n >= .71 and n <= .80 then v8+=1
        if n >= .81 and n <= .90 then v9+=1
        if n >= .91 and n <=   1 then v10+=1
        
    next
    
    print
    print ".00 to .10 = " ; v1
    print ".11 to .20 = " ; v2
    print ".21 to .30 = " ; v3
    print ".31 to .40 = " ; v4
    print ".41 to .50 = " ; v5
    print ".51 to .60 = " ; v6
    print ".61 to .70 = " ; v7
    print ".71 to .80 = " ; v8
    print ".81 to .90 = " ; v9
    print ".91 to   1 = " ; v10

    sleep
    
loop until inkey = chr(27)

end

[deltarho[1859]]

it never generates values less than ( 2 ^ 32 )

The lowest generated value is greater than 9 digits...

It would given half the chance but 10,000,000 tests is small and 2^32 is minuscule compared with 2^64.

Suppose the following 1000 pixel ruler represents 2^64.



Log(2^64/1000)/Log(2) = 54.03

So, values below 2^54 will fall below half of the first smallest graduation.

As for 2^32 we would need a microscope to see where its range is at the beginning of the ruler ie divide one pixel with 2^22.

Now start generating 'int( rnd*(2^64) )'. How many of 10,000,000 should we expect to fall into the 'microscopic region'?

We should not expect any.

If you can't fix why INT( RND * ( 2 ^ 63 ) ) never generates a value less than ( 2 ^ 32 ) , then don't post anything in this topic..

Blimey!

'Never' is a bit strong. It is possible to get a value to fall into the 'microscopic' region but the likelihood is 'closing in' on zero. We need to push the boat out on the number of tests taken - and by push the boat out I mean push the boat out.

It doesn't even hardly , get any values below ( 2 ^ 56 )

See my comment re 2^54 above.

Only the FB coders can fix the problem....

So the problem is in the INT() function...

We don't have a problem.

I was hoping that my quick 'drive by' first post would be enough. This is pretty trivial arithmetic and I am at a loss to think of another way of explaining how puny 2^32 is compared to 2^64.

[albert]

@deltarho[1859]

Your post doesn't change the fact that INT( RND * ( 2 ^ 63 ) ) never returns a value below 2 ^ 32 ...Even after 10,000,000 loops...

Here's some code that returns below ( 2 ^ 32 ) ... But it hardly ever returns below 65536

Code: Select all

screen 19

do
    
    dim as ulongint out_array( 0 to 7 )  
    dim as ulongint in_array( 0 to 7 ) : in_array(0) = 0 
    for a as longint = 1 to 7
        in_array(a) = ( 2 ^ ( a * 8 ) )
    next
    
    dim as double n = 0
    dim as ulongint value = 0
    randomize
        
    for a as longint = 1 to 1000000
        
        n = rnd / 1e9
        value = int( n * (2^63) )
        
        for b as longint = lbound(in_array) to ubound(in_array)
            if value >= in_array(b) and value < in_array(b+1) then out_array(b)+=1
        next
        
    next
    
    print"================================================"
    for b as longint = lbound(in_array) to ubound(in_array)
        locate , 1 : print b*8 ; " bits = " ; in_array(b);
        locate ,40 : print out_array(b)
    next
    
    sleep
    
loop until inkey = chr(27)

end

[deltarho[1859]]

Your post doesn't change the fact that INT( RND * ( 2 ^ 63 ) ) never returns a value below 2 ^ 32 ...Even after 10,000,000 loops...

The chance of returning a value below 2^32 is 2^32/2^63 that is 2,147,483,648 to 1 against. The chance of winning the Powerball lottery is 292,201,338. So, the chance of winning the Powerball lottery is over seven times greater than returning a value below 2^32 using Int(Rnd*2^63).

How about this one: The odds of being a lightning victim in the US in any one year is 1 in 700,00 ie over 3000 times more likely than returning a value below 2^32 using Int(Rnd*2^63).

There is one way to disprove your claim that "INT( RND * ( 2 ^ 63 ) ) never returns a value below 2 ^ 32" and that is to push the boat out on iterations as I suggested earlier.

Instead of 10,000,000 iterations I tried 2^32 and kept my fingers crossed - in theory I should get one value below 2^32 but, of course, that is not guaranteed. I got nothing.

OK. If what I have written so far is true then there exists a number of iterations which will give at least one value below 2^32.

So, I tried 2^34 iterations ie four times as many as 2^32. 2^34 is over 17 billion.

I got six values below 2^32.

The computation took 706 seconds on my machine, which is no slouch.

"INT( RND * ( 2 ^ 63 ) ) never returns a value below 2 ^ 32" is then a false statement provided that a sufficient number of iterations are computed, as predicted.

I have to rest my case now - there is nothing else that I can do.

[jj2007]

Your post doesn't change the fact that INT( RND * ( 2 ^ 63 ) ) never returns a value below 2 ^ 32 ...Even after 10,000,000 loops...

The chance of returning a value below 2^32 is 2^32/2^63 that is 2,147,483,648 to 1 against. The chance of winning the Powerball lottery is 292,201,338. So, the chance of winning the Powerball lottery is over seven times greater than returning a value below 2^32 using Int(Rnd*2^63).

Take it easy - I also had to look twice before I understood. It's not intuitive that the algo "never" produces such a "big" number as 2^32. So it takes a while until it makes "click" in your brain ;-)

[deltarho[1859]]

Take it easy

Are you saying that what I regard as elementary arithmetic may not be as elementary as I think it is. I thought that my post with the ruler screenshot was a pretty good job at 'dumbing down' and should have 'nailed it'. You had an issue with one of the topics of my PCG32II which I thought was a good job at dumbing down. Since you are, in my opinion, one of the forum's bright sparks it seems to me that I am not as good at explaining things as I thought I was. Dodicat did drop a hint with his "Try dividing 2^32/2^64" comment. If we do that then we get 2.328306e^-10 showing that "But 2^32 is very far left of the mean of the range.". I figured that a lengthier explanation was warranted and spent three posts after my first trying to do just that - to no avail, it seems. I don't want to dumb down too much otherwise folks are going to get their backs up. Oh, what a predicament. Maybe I should ask you to proofread my technical rambling before posting. What are your fees? <smile> Perhaps I should stop posting. 'Been there before, haven't we? I did expect to be out of this thread as fast as a whippet on my first post. This is only the second thread I have entered since the end of December, excepting the WinFBE thread, and with the other thread, I thought that I would be out as fast as a whippet and got 'bogged down' in that one.

Apologies to albert for doing a poor job.

[Tourist Trap]

From what I understand, this is possible to get randomly a number lesser than 2^32 in a test over the 1-2^64 interval, but it's a rare event. Because 2^32 looks big but is ridiculously small compared to 2^64. Am I right?

[deltarho[1859]]

Spot on, TT. How would like a job translating my lengthy posts? <laugh>

I forget how it goes exactly but there is an event in our Sun which, considered in isolation, is so rare that it is very nearly non-existent. However, this event occurs at, sorry about the pun, an astronomical number of times such that the likelihood of something happening is exceptionally large. Read that as something which approaches infinitesimal being multiplied by something which approaches infinity. Things like this happen quite a lot and if any one of them was slightly 'off key' our universe would not exist. Some folks take the view that being 'on key' was no accident. I take the opposing view and reckon that big bangs are two a penny and every now and then one or more actually amounts to something.

[dodicat]

Albert's discussions very often end up in astronomy.
I cannot explain this phenomenon, It happened in circles, it happens in squares with great regularity.
Deltarho's suggestion that big bangs are going on like Gatling guns out there is interesting but not surprising.
I would postulate that if ever any great revelations came forth in freeBASIC ( perpetual motion fields, prime number fields, cosmos fields e.t.c.) then they will surface in one of Albert's deliberations, and he himself alone will claim any prizes and rightly so.

[sean_vn]

If the uniform random numbers fall on a line between 0 and 1 then you will get less than 0.5 (ie anywhere on the lower half) half the time, less than 0.1 (anywhere on the lower tenth) one over ten of the time, less than 0.01 one over a hundred of the time etc.

If you want an equal probability of getting really large or really small numbers, say for an evolutionary algorithm you could use something like exp(-c*rnd). Where c determines the lowest number. Then the probability of getting a number around 0.1 is the same as getting a number around 0.0001. Very different from the uniform distribution.

[Tourist Trap]

If the uniform random numbers fall on a line between 0 and 1 then you will get less than 0.5 (ie anywhere on the lower half) half the time, less than 0.1 (anywhere on the lower tenth) one over ten of the time, less than 0.01 one over a hundred of the time etc.

If you want an equal probability of getting really large or really small numbers, say for an evolutionary algorithm you could use something like exp(-c*rnd). Where c determines the lowest number. Then the probability of getting a number around 0.1 is the same
as getting a number around 0.0001. Very different from the uniform distribution.

Does this program illustrate what you say?

Code: Select all

 #include "fbgfx.bi"

dim as integer  dskW, dskH
screenControl fb.GET_DESKTOP_SIZE, dskW, dskH

'fb1.06 win32, 64bits:
'bug?? --> on my win10, full desktop size is not returned well by fb.GET_DESKTOP_SIZE, res= 1920*1080

screenRes 0.79*dskW, 0.69*dskH, 32, 2

'inspired of the documentation:
'' define clipping area
Draw String ( 0.19*dskW, 0.09*dskH - 16), "proba", rgb(250,40,120)
Draw String (0.79*dskW\2 - 8*20, 0.62*dskH), "normalized of the new standard value mapping", rgb(250,120,40)

View ( 0.19*dskW, 0.09*dskH)-(0.6*dskW - 1, 0.6*dskH), rgb(10,0,50), rgb(200,200,0)   
Window (-0.05, -0.05)-(1.05, 1.05)                
    '' Draw X axis
    Line (0,0)-(1,0), rgb(250,80,0)
    
    '' Draw Y axis
    Line (0,0)-(0,1), rgb(250,0,80)
    
    '' draw title
    Draw String ( .62, .78 ), "Y = X", rgb(240,250,20)
    Draw String ( .32, .06 ), "Y = 2^X with X in 0..64", rgb(240,50,200)
    dim as single xMin, xMax
    xMin    = 0
    xMax    = 64
    
    Dim As Single x, y, s
    '' compute step size
    s = 1/PMap(1, 0)
    
    '' plot the function
    For x = xMin To xMax step s
      'transform
      y = 2^x
      'normalize
      var xn = (x - xMin)/(xMax - xMin)
      var yn = (y - 2^xMin)/(2^xMax - 2^xMin)
      circle (xn, yn), 0.004, rgb(100 + xn*100, yn*255, 200 - yn*20)
      PSet(xn, yn), rgb(0,240,200)
      Pset(xn, 0.5), rgb(100,200,100)
      Pset (xn - 0.003, xn), rgb(50 + xn*200, 50 + yn*200, 200 - yn*20)
      Pset(xn, xn), rgb(200,200,100)
    Next x
Window
View

getKey()
'(eof)

My math are far, do someone know if a probability distribution must have its integral equal to 1, or something like that, to be legit? or I'm confounding ... can't remember what.

[dodicat]

Nice one TT
You will have to use screenlist to see available sizes for full screen on your box.

What does sean_vn mean by (around) .1 or (around) .0001?
In fb it depends on which algorithm you use for rnd (I define (around) here by a change to single)
Or does sean_vn a mathematical around which doesn't involve computer floating point numbers.

Code: Select all

 
dim as integer counter(1 to 9)
randomize ,0   '1  2  3  4    
do
    if csng(rnd)=.1! then counter(1)+=1:locate 4,2 :print ".1  ";counter(1):goto nxt
    if csng(rnd)=.2! then counter(2)+=1:locate 5,2 :print ".2  ";counter(2):goto nxt
    if csng(rnd)=.3! then counter(3)+=1:locate 6,2 :print ".3  ";counter(3):goto nxt
    if csng(rnd)=.4! then counter(4)+=1:locate 7,2 :print ".4  ";counter(4):goto nxt
    if csng(rnd)=.5! then counter(5)+=1:locate 8,2 :print ".5  ";counter(5):goto nxt
    if csng(rnd)=.6! then counter(6)+=1:locate 9,2 :print ".6  ";counter(6):goto nxt
    if csng(rnd)=.7! then counter(7)+=1:locate 10,2 :print ".7  ";counter(7):goto nxt
    if csng(rnd)=.8! then counter(8)+=1:locate 11,2 :print ".8  ";counter(8):goto nxt
    if csng(rnd)=.9! then counter(9)+=1:locate 12,2 :print ".9  ";counter(9)
    nxt:
    loop 

Or a much broader (around)

Code: Select all

 
dim as integer counter(1 to 10)
randomize ,0   '1  2  3  4 
do
    select case (rnd)
    case 0 to .1 : counter(1)+=1:locate 4,2 :print "0  to .1  ";counter(1)
    case .1 to .2: counter(2)+=1:locate 5,2 :print ".1 to .2  ";counter(2)
    case .2 to .3: counter(3)+=1:locate 6,2 :print ".2 to .3  ";counter(3)
    case .3 to .4: counter(4)+=1:locate 7,2 :print ".3 to .4  ";counter(4)
    case .4 to .5: counter(5)+=1:locate 8,2 :print ".4 to .5  ";counter(5)
    case .5 to .6: counter(6)+=1:locate 9,2 :print ".5 to .6  ";counter(6)
    case .6 to .7: counter(7)+=1:locate 10,2:print ".6 to .7  ";counter(7)
    case .7 to .8:counter(8)+=1:locate 11,2 :print ".7 to .8  ";counter(8)
    case .8 to .9:counter(9)+=1:locate 12,2 :print ".8 to .9  ";counter(9)
    case .9 to  1:counter(10)+=1:locate 13,2:print ".9 to 1   ";counter(10)
    end select
loop until len(inkey)
sleep

 

[deltarho[1859]]

Does this program illustrate what you say?

No.

The result of counting_pine's code is indicative of a uniform distribution but that has nothing to do with albert's flawed logic in the opening post saying the mid-point of 2^64 is 2^32. That is a misunderstanding of exponentiation.

sean_vn's second paragraph went well off topic.

My rambling on big bangs was also off topic.

Time for me to get back to my project but before going I reckon that there is more than one universe 'on key' but the others have a different number of spatial and temporal dimensions and they collide resulting in dark matter. You read it here first but, as dodicat mentioned, that may well turn up in one or more of Einstein's equations. <smile>