PCG32II Help file

General FreeBASIC programming questions.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: PCG32II Help file

Post by deltarho[1859] »

I do not understand the Overload functionality. If I specify pcg.range(1,123) will it then invoke the Long version?
Yes.

If either or both parameters is a float then the float range will be used.

Code: Select all

#Include "PCG32II.bas"
Dim As pcg32 pcg
Print pcg.Range(1,500);" ";pcg.Range(1.,500)
Print pcg.Range(1,600);" ";pcg.Range(1,600.)
Print pcg.Range(1,700);" ";pcg.Range(1.,700.)
sleep
and I got

Code: Select all

 376  368.1740036648698
 150  453.6680366187356
 451  342.9242223035544
Provoni
Posts: 513
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: PCG32II Help file

Post by Provoni »

Okay thanks.

From the help file:
The generator is 'warmed up' during MyRandomize.

Code: Select all

' Warm up generator
  For i As Ulong = 1 To 200
    this.rand()
  Next
Why?
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: PCG32II Help file

Post by deltarho[1859] »

Most generators have a heavy bias in the bits of their early generated random numbers ie too many ones or too many zeros. It doesn't take long for the bias to vanish. Sebastian Vigna published a graph of quite a few generators showing when the bias vanished; some vanished very rapidly and some took their time but I cannot find the paper he wrote where the graph is. By 'took their time' I mean up to 100 generated numbers. Choosing 200 should be OK for all generators. There is one generator where the author reckons no warming up is required. The safe bet is to ignore that - the first 200 of his generator only takes 1.2 microseconds on my machine so that would be impossible for us to tell it had been done. If we use a generator for only 50, say, numbers and don't warm it up we could be in serious trouble as the randomness may be diabolical. All of my published generators have a 'warm up'. None of the FB generators have a 'warm up' but that does not bother me because I don't use any of them. Image I should broadcast that from the roof tops but very few people would take a blind bit of notice.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: PCG32II Help file

Post by deltarho[1859] »

Found the paper, the graph is on page 12: Further scramblings of Marsaglia’s xorshift generators

It was published in the 'Journal of Computational and Applied Mathematics', May 2017 so it is not that old.

The heavy bias was toward zeros and not as I wrote earlier - memory fog.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: PCG32II Help file

Post by deltarho[1859] »

Sometimes I will read something and no bells ring and sometime later, perhaps days, bells do ring and I got back to the statement. This might happen with many people, I don't know.

Anyway, Provoni, you wrote this a few days ago.
Nope, my program (AZdecrypt) can use up to 65,536 threads (current artificial limit)
This is from one of my Help files.
The buffer is attended to fairly quickly and we may have a lot of them - 4096 in the case of a 1GB file. From Microsoft: "An application that creates and destroys a large number of threads that each run for a short time. Using the thread pool can reduce the complexity of thread management and the overhead involved in thread creation and destruction." Thread creation, on my machine, costs about four times as much as a thread submission with a Thread Pool so the latter was employed.
Your AZdecrypt may benefit from using a thread pool. I am not an expert of thread pooling and my use is a simple implementation.
Provoni
Posts: 513
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: PCG32II Help file

Post by Provoni »

Thanks for mentioning. AZdecrypt keeps its threads active, they just wait for input to arrive with a sleep statement added in.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: PCG32II Help file

Post by deltarho[1859] »

@Provoni

PCG32II has been updated. The asm in the integral range function has been replaced by code devised by dodicat giving an increase of 60% in the throughput.

You can get the new package here.

That 60% increase is for 32-bit mode, with 64-bit mode the increase is 25%. PCG32II is faster overall in 32-bit mode. Some folk nowadays don't give 32-bit the time of day but very often it runs faster than 64-bit.
Post Reply