FB RANDOMIZE() and RND() seed parameters ignore the mantissa

[MrSwiss]

I think it is a good addition. I did not know before this that the mantissa was ignored in Randomize. I think it is good to have it listed as above.

Apart from the fact, that the fraction-part of the Double is ignored in Randomize, it whould be more beneficial to state clearly:
"multiple calls to randomize() are not recommended in general, exceptions may exist".

NOTE: different wording, less technical language (better understood by beginners).

[fxm]

There is already almost such a formulation:

.....
However, it is generally not worth calling Randomize twice with unpredictable seeds anyway, because the second sequence will be no more random than the first. In most cases, the Mersenne twister should provide a sufficiently random sequence of numbers, without requiring reseeding between Rnd calls.
.....

[MrSwiss]

Apart from the fact, that the fraction-part of the Double is ignored in Randomize().

That is the proposed new text (in red), instead of the 'mantissa' reference.

BTW: both of those terms are not yet part of the glossary (of technical terms).
(fraction can at least be referenced with: "frac(double) as double")

[fxm]

Maybe like this:

.....

For any given seed, each algorithm will produce a specific, deterministic sequence of numbers for that seed. If you want each call to Randomize to produce a different sequence of numbers, a seed that is not quite predictable should be used - for example, the value returned from Timer. Omitting the seed parameter will use a value based on this.
Note: using the Timer value directly as a parameter will produce the same seed if used more than once in the same second. However, it is generally not worth calling Randomize twice with unpredictable seeds anyway, because the second sequence will be no more random than the first.
In most cases, the Mersenne twister should provide a sufficiently random sequence of numbers, without requiring reseeding between Rnd calls. So multiple calls to Randomize are not recommended in general.

When you call Randomize with the QB compatible algorithm, part of the old seed is retained. This means that if you call Randomize several times with the same seed, you will not get the same sequence each time. To get a specific sequence in QB compatible mode, set the seed by calling Rnd with a negative parameter.

Note:

• - After the Randomize call copies the user seed argument (passed by value) into a local Double variable, the result is then casted to Ulong before use. So the fraction-part of the Double is ignored in Randomize.
  - For fbc version >= 1.08, Randomize is became thread-safe (by using an internal mutex), but not thread specific. Structures for other random number generators are also now available in the standard header "fbmath.bi".

.....

[MrSwiss]

Maybe like this: ...

Looks good, easy to live with, for different levels of know-how (I think so).

[fxm]

Done:
- KeyPgRandomize → fxm [added description complement]

[adeyblue]

- After the Randomize call copies the user seed argument (passed by value) into a local Double variable, the result is then casted to Ulong before use. So the fraction-part of the Double is ignored in Randomize.
- For fbc version >= 1.08, Randomize became thread-safe (by using an internal mutex), but not thread specific. Structures for other random number generators are also now available in the standard header "fbmath.bi"......

IMO The red parts don't need to be there. This documentation is for 'how to use', 'how it works' is FB developer information.

[deltarho[1859]]

From Help

Code: Select all

Parameters
 
seed
 A Double seed value for the random number generator. If omitted, a value based on Timer will be used instead.

That should not have been written in the first place.

Anyone reading that would expect the fractional part of a double seed would be honoured. That is not true as shown by the opening post. The only generator keeping the fractional part is generator #4.

Code: Select all

Note: using the Timer value directly as a parameter will produce the same seed if used more than once in the same second.

The reason for that, of course, is because the fractional part is clipped with all generators excepting generator #4. The reason is not given.

Code: Select all

However, it is generally not worth calling Randomize twice with unpredictable seeds anyway, because the second sequence will be no more random than the first.

That is not the reason why Randomize should not be called twice. It should not be called twice because it is possible to enter the sequence just before a section which has already been used. So, it is not just a waste of time, it may have damaging consequences.

So multiple calls to Randomize are not recommended in general. That is pointless as it has already been said.

- After the Randomize call copies the user seed argument (passed by value) into a local Double variable, the result is then casted to Ulong before use. So the fraction-part of the Double is ignored in Randomize.

Again: "So what?" A user needs to know what is happening, as per the opening post, and not what is causing it to happen.

I am sorry guys but what is being proposed is not good enough and is now in the Wiki.

This documentation is for 'how to use', 'how it works' is FB developer information.

Spot on!

[fxm]

I can't help but think that rather than nitpicking over small drafting details, I would prefer that your energies be spent on complete shortcomings that still exist in the documentation (for example, to finalize the 'Programmer's Guide' by filling in the 'External Graphics File Formats' page in 'Graphics')!

"It is easy to criticize, but hard to act".

[deltarho[1859]]

What I know about graphics can be put on the back of a postage stamp.

You may recall that sections of Help's RND were rewritten because of my intervention.

It is not my fault that the section on Randomize was badly written and is now worse.

Here is another way to generate a random Ulong seed:

Code: Select all

Function RandomSeed() as Ulong
Dim As Ulong Seed
Asm
  rdtsc ' Get a fast changing number from the processor
  mov Dword Ptr [Seed], eax
End Asm
Return Seed 
End Function

Randomiize RandomSeed, 3
Print Rnd
Sleep

What should be in the Wiki is a tip to use a random Ulong for a seed.

So far, I have presented four ways of doing that.

How much action do you need?

[fxm]

Code: Select all

Note: using the Timer value directly as a parameter will produce the same seed if used more than once in the same second.

The reason for that, of course, is because the fractional part is clipped with all generators excepting generator #4. The reason is not given.

.....

- After the Randomize call copies the user seed argument (passed by value) into a local Double variable, the result is then casted to Ulong before use. So the fraction-part of the Double is ignored in Randomize.
Again: "So what?" A user needs to know what is happening, as per the opening post, and not what is causing it to happen.

Two somewhat contradictory remarks.

This documentation is for 'how to use', 'how it works' is FB developer information.

Spot on!

Often so that the "how to use" is easily learnable, it is useful to also explain the "why this".


But I will still try to improve this documentation page.
[edit]
KeyPgRandomize → fxm [text improvement attempt]

[deltarho[1859]]

→ fxm [text improvement attempt]

The description of seed is much better and the statement beginning "Note: for all algorithms except algorithm #4, ..."

The statement beginning "However, it is generally not worth calling Randomize twice ..." needs improving. There is more to it than "... will be no more random than the first." Sequence overlapping could be very problematic and there is no way of knowing whether it will occur or not.

[fxm]

Sequence overlapping could be very problematic and there is no way of knowing whether it will occur or not.

Does this phenomenon only appears when multi-threading?

[deltarho[1859]]

Does this phenomenon only appears when multi-threading?

No.

When we use Randomize we enter a generator's sequence at a particular point. If we noted the first 100 or so RND values and then used Randomize again we could enter the sequence a little later than the first use of Randomize. From that point on we will see a repetition of RNDs.

The larger the period of the generator the less likely this will occur, but the fact remains it could happen with dire consequences and there is no way that we can tell that it is about to happen. With a counter based PRNG we will know by virtue of reusing a counter value. With non-counter based PRNGs we cannot know.

So, it is a case of use Randomize twice at our peril.

[fxm]

KeyPgRandomize → fxm [text improvement]