random intrinsics for large reals

NAVIGATION

CATEGORIES

Development

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Development

random intrinsics for large reals
6 answers - 1920 bytes -
:ADDPATCH fortran:
Hello world,
the attached patch fixes PR 28452. It also speeds up random number
generation for REAL(kind=4) quite nicely (by about a factor of 2.5).
I have regression-tested this on i686-pc-linux-gnu. I don't have
a system with REAL(16), nor do I have a system where FLT_RADIX is
16 (IBM/360), so I would appreciate if this was tested before
committing.
K?
Thomas
2006-07-27 Thomas Koenig <Thomas.Koenig (AT) online (DOT) de>
PR libfortran/28542
* Makefile.am: Remove normalize.c.
* aclocal.m4: Regenerate using aclocal 1.9.3.
* Makefile.in: Regenerate using automake 1.9.3.
* libgfortran.h: #include <float.h>.
Define GFC_REALDIGITS and GFC_REALRADIX.
Remove prototypes for normalize_r4_i4 and normalize_r8_i8.
* intrinsics/random.c (top level): Add prototypes for
random_r10, arandom_r10, random_r16 and arandom_r16.
(rnumber_4): New static function.
(rnumber_8): New static function.
(rnumber_10): New static function.
(rnumber_16): New static function.
(top level): Set to kiss_size to 12 if we have
REAL(KIND=16), to 8 otherwise.
Define KISS_DEFAULT_SEED_1, KISS_DEFAULT_SEED_2 and
KISS_DEFAULT_SEED_3.
(kiss_random_kernel): Take argument to differentiate
between different random number generators.
(random_r4): Add argument to call to kiss_random_kernel,
use rnumber
(random_r8): Likewise.
(random_r10): New function.
(random_r16): New function.
(arandom_r4): Add argument to call to kiss_random_kernel,
use_rnumber
(arandom_r8): Likewise.
(arandom_r10): New function.
(arandom_r16): New function.
* intrinsics/rand.c (rand): Use shift and mask.
* runtime/normalize.c: Remove.
2006-07-27 Thomas Koenig <Thomas.Koenig (AT) online (DOT) de>
PR libfortran/28542
* gfortran.dg/random_3.f90: New test.
No.1 | | 1557 bytes | |
Thu, Jul 27, 2006 at 10:46:49PM +0200, Thomas Koenig wrote:
:ADDPATCH fortran:

the attached patch fixes PR 28452. It also speeds up random number
generation for REAL(kind=4) quite nicely (by about a factor of 2.5).

I have regression-tested this on i686-pc-linux-gnu. I don't have
a system with REAL(16), nor do I have a system where FLT_RADIX is
16 (IBM/360), so I would appreciate if this was tested before
committing.

I'll review this patch on Saturday. Note, I've read the
patch(es) you've attached to the bugzilla report.

Have you run any tests on the quality? A hard drive failure
caused me to loose the few tests that I had. I wrote a new
equidistance test (ie., divide the interval [0,1) into binsi
and count the number of values in each bin) this morning.
current rng shows

Number of random numbers: 100000000
Number of bins: 100
998616 1000019 1000234 1001897 999741 1000524 999975 1000251 1000366 998753
998616 1000019 1000234 1001897 999741 1000524 999976 1000251 1000365 998753
84.44992
84.4386240000000
t1 - t0 = 11.29466 seconds

That's 100 million real(4) and real(8) random values split into
100 bins. The chi-square value is nominally 84.4, which suggest
that the current implement is a good generator with respect to
this specific test. This also shows the counts for the first 10
bins.

Note, that's 11.3 seconds of cpu time to generate the random
numbers and to compute the chi-square values.
No.2 | | 479 bytes | |
Thu, Jul 27, 2006 at 02:09:36PM -0700, Steve Kargl wrote:

Have you run any tests on the quality?

No, I just sort of assmed it would be K with the KISS generator
:-) I would appreciate if you could run your test on my generator,
as well.

If anybody knows good random number generator testing software,
I would appreciate a pointer.

It would also be interesting what speed numbers you get for the
testing benchmark.

Thomas
No.3 | | 270 bytes | |
I just found one thing that was wrong with my patch: rand() could
return 1.0 in some cases because of an incorrect shift. I have
attached the correct patch to rand.c.
If you want me to resubmit the whole patch, please tell me so :-)
Thomas
No.4 | | 819 bytes | |
Fri, Jul 28, 2006 at 07:32:16AM +0200, Thomas Koenig wrote:
Thu, Jul 27, 2006 at 02:09:36PM -0700, Steve Kargl wrote:

Have you run any tests on the quality?

No, I just sort of assmed it would be K with the KISS generator
:-) I would appreciate if you could run your test on my generator,
as well.

If anybody knows good random number generator testing software,
I would appreciate a pointer.

You missed the IRC discussion tonight (morning?).

It would also be interesting what speed numbers you get for the
testing benchmark.

I only have the one test, which I intend to run on Saturday.
Having read your code, I suspect that your reworked code
will pass. I'll also add a real(10) chunk. If time permits,
I may try to write run up and run down tests.
No.5 | | 604 bytes | |
Fri, Jul 28, 2006 at 07:44:26AM +0200, Thomas Koenig wrote:
I just found one thing that was wrong with my patch: rand() could
return 1.0 in some cases because of an incorrect shift. I have
attached the correct patch to rand.c.

If you want me to resubmit the whole patch, please tell me so :-)

That won't be necessary. Hopefully, no one uses rand().

thing I want meant to ask earlier concerns the masking.
For example with the real(4), you grab 32-bit then mask off
a small portion to give you the 24-bits. Is this ok with
both little and big endian hardware?
No.6 | | 523 bytes | |
Thu, Jul 27, 2006 at 10:53:04PM -0700, Steve Kargl wrote:

thing I want meant to ask earlier concerns the masking.
For example with the real(4), you grab 32-bit then mask off
a small portion to give you the 24-bits. Is this ok with
both little and big endian hardware?

The masking is done with the unsigned int _values_, independent of
representation (which could be big-endian, little-endian or NUXI).
After that, the unsigned value is converted to real(4).

Regards
Thomas

Re: random intrinsics for large reals

QUESTION ON "Development"

EMSDN.COM

Archive for 'random intrinsics for large reals' by Thomas Koenig

Development

random intrinsics for large reals