... If you want a sequence, you use the RANDOMIZE keyword - with no parameter it sets the seed to the timer. With a numeric parameter, it uses that as the seed.
That's kinda the point, no?
Yes, it is. That's what FBSL would do too:
... if RANDOMIZE uses the same constant argument, the new sequences will also be constant, albeit different from when used without an argument. RANDOMIZE TIMER is redundant in FBSL BASIC because that's what its RANDOMIZE would do on default -- much more often than randomizing with a constant argument.
Well, that's how SpecBAS does it - the random seed at startup is determined by system time in ms. This way every time a program is run, you get random numbers, not a sequence...
That's kinda the point, no?
No, at least not to
my point. FBSL i) incorporates an own ANSI C module, and ii) is designed to extensively use 3rd party DLLs usually written in C and linked against msvcrt.dll (system standard as opposed to crtdll.dll which isn't). FBSL BASIC calls to
RANDOMIZE,
RANDINT and
RND are guaranteed to generate the exact same results as its own DynC and 3rd party calls to
srand() and
rand() at all times for 100% compatibility reasons.
How much do we want our data refined
for us?
And ... what compatibility does SpecBAS claim, Paul?
........
Ah, speed, the magic word...
........
Rand() ; RANDOMIZE using rdtsc
........
What will you do with your Rand() under Windows 98 on a 486 chip, Jochen? FBSL runs on and under everything that's at least Windows 95 RC2 (with socket support) and has 32MB of RAM.
I used NOW as the seed for this example as the challenge was to return a single random character. If I were to generate a list of random characters, 1 second seeding isn't sufficient. I use the RANDOMIZE(gfx::Time()) SDL_gfx extension module function for millisecond resolution of randomness.
In fact, all these minutiae are
extremely platform dependent, John. For any serious work with random numbers like e.g. cryptography, a specialized 3rd party library would be highly advisable.