Fiddling around with random #s and odds.

[Dio]

wait a minute, why doesn’t this work?

Code:

dim as long n,celing
randomize timer
s = timer
celing = 2000000
do:loop until int(rnd*celing)+1 = 1234567
? done
? timer - s:sleep

also,

i ran the following code in qbasic.

Code:

RANDOMIZE TIMER
s = TIMER
celing& = 2000000
DO: LOOP UNTIL INT(RND * celing&) + 1 = 1234567
PRINT done
PRINT TIMER - s: SLEEP

it successfully found 1234567 in:

first run completed in:

3.5 seconds

second:

2) 1/5 of a second

henceforth:

3) .75 of a second

4) 3.8 seconds

----

regardless of the amount of time it took, it still worked.

[Zack]

So:
-it works in QB
-it doesn't work in FB, at least on Windows.
So it's an FB problem...perhaps FB's random function is weighting certain ranges. Can somebody with a Linux build of FB try it?

[Moneo]

"Freebasic is like QB, except it doesn't work" LOL.

*****

[Neo]

The only number between 1234500 and 1234600 I found using your programs and FB is 1234559.

I think FB's RND function or internal calculations is lacking precision.

[Zack]

Thanks Neo (how've you been, by the way? Aren't you taking aerospace studies or something?).
I guess somebody should tell the FB people about this.

[Antoni Gual]

RND used the OS's C runtime rand function until version 0.17 jun-30 unstable. The rand function in Windows' library has a granularity of just 15 bits, so probably it is unable of generating exactly 1234567. For comparison QB's RND has 24 bits granularity.

In the present version compiled from CVS you have a different RND depending on the -lang option passed in the command line of the compiler:
With -lang qb you have a RND mimicking exactly QB's generator.
With -lang fb (the default) you have a Mersenne Twister algorithm with 32 bits granularity.
With -lang deprecated it behaves as 0.16 version, using C runtime's rand

You have too a fourth "fast" random algorithm and a second argument to RANDOMIZE allowing to select the algorithm used...

So perhaps some of you updated to the CVS version, it would explain why you get 1234567. Or you are using the DOS or Linux version where the granularity of rand is 31 bits..

More in the wiki:
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgRnd

[Moneo]

That's what happens when you run Windows...
igh:

Skyler,
Why don't you ever offer some technical feedback, comments, or ideas to threads? It seems like all you do is kibitz.

*****

[Zack]

RND used the OS's C runtime rand function until version 0.17 jun-30 unstable. The rand function in Windows' library has a granularity of just 15 bits, so probably it is unable of generating exactly 1234567. For comparison QB's RND has 24 bits granularity.

In the present version compiled from CVS you have a different RND depending on the -lang option passed in the command line of the compiler:
With -lang qb you have a RND mimicking exactly QB's generator.
With -lang fb (the default) you have a Mersenne Twister algorithm with 32 bits granularity.
With -lang deprecated it behaves as 0.16 version, using C runtime's rand

You have too a fourth "fast" random algorithm and a second argument to RANDOMIZE allowing to select the algorithm used...

So perhaps some of you updated to the CVS version, it would explain why you get 1234567. Or you are using the DOS or Linux version where the granularity of rand is 31 bits..

More in the wiki:
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgRnd

1234567=(x*2000000)+1
x=1234566/2000000
x=0.617283
So you're saying that my version of FB is unable to generate 0.617283 because the RND function doesn't generate numbers to that precision?

[TheAdventMaster]

I'm on windows, and I ran it like 10 times. Each time passed within a second or less. It works just fine here.

[Antoni Gual]

Did you ever installed one of the updates mintained by Eric Cowles (1000101) or before November, by Pritchard? If you did that you are using the new RND