Home > Archive > Fortran > June 2007 > random number
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| nakisa 2007-06-22, 4:16 am |
| hi every body
i need to use random number in program . i see in fortran's help that
there is an intrinsic function named "rand " that generate random
number .
but it doesn't works ???
can anybody helps me ?
best,nakisa
| |
| Steven G. Kargl 2007-06-22, 4:16 am |
| In article <1182486961.791024.97500@o61g2000hsh.googlegroups.com>,
nakisa <nakisa.nooraee@gmail.com> writes:
> hi every body
> i need to use random number in program . i see in fortran's help that
> there is an intrinsic function named "rand " that generate random
> number .
> but it doesn't works ???
> can anybody helps me ?
1) What do you mean by 'doesn't work'?
2) Historically, rand is mapped to the Unix rand library routine,
which is perhaps one of the worse choices for a PRNG in this
day and age.
3) Use the standard conforming random_number intrinsic.
4) If you don''t want to use random_number, then go to Alan
Miller's website and find one that works for you.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| meek@skyway.usask.ca 2007-06-22, 10:07 pm |
| In a previous article, nakisa <nakisa.nooraee@gmail.com> wrote:
>hi every body
>i need to use random number in program . i see in fortran's help that
>there is an intrinsic function named "rand " that generate random
>number .
>but it doesn't works ???
>can anybody helps me ?
>best,nakisa
>
Did you initialize the seed to an arbitrary integer ?
What does RAND need ? +ve, -ve ?
Chris
| |
| Ingo Thies 2007-06-22, 10:07 pm |
| Hi, nakisa, at 21 Jun 07 you wrote:
> i need to use random number in program . i see in fortran's help that
> there is an intrinsic function named "rand " that generate random
> number .
You may try the Mersenne Twister:
http://www.math.sci.hiroshima-u.ac....mat/MT/emt.html
There are codes available in various languages, including Fortran.
cu
Ingo
| |
| nakisa 2007-06-25, 10:07 pm |
| hi
i use
CALL RANDOM_NUMBER(m1)
in program . the problem is that this program always generate the same
number ! it doesn't mean random number !does it ? so ,i mean it
doesn't work
| |
| meek@skyway.usask.ca 2007-06-25, 10:07 pm |
| In a previous article, nakisa <nakisa.nooraee@gmail.com> wrote:
>hi
>i use
>
>CALL RANDOM_NUMBER(m1)
>in program . the problem is that this program always generate the same
>number ! it doesn't mean random number !does it ? so ,i mean it
>doesn't work
>
You could read the manual - or you could try
the opposite sign for m1
Chris
| |
| Beliavsky 2007-06-25, 10:07 pm |
| On Jun 25, 3:09 pm, nakisa <nakisa.noor...@gmail.com> wrote:
> hi
> i use
>
> CALL RANDOM_NUMBER(m1)
> in program . the problem is that this program always generate the same
> number ! it doesn't mean random number !does it ? so ,i mean it
> doesn't work
To get different sets of random variates in each run of the program,
you can insert a call to the intrinsic subroutine random_seed before
calling random_number, as in the following program
program xrandom_number
implicit none
integer, parameter :: dp = kind(1.0d0), n = 10
real(kind=dp) :: xx(n)
call random_seed()
call random_number(xx)
print*,"xx =",xx
end program xrandom_number
..
| |
| nakisa 2007-06-25, 10:07 pm |
| hi Chris
the problem is the value of m1 , not it's sign !!
| |
| e p chandler 2007-06-25, 10:07 pm |
| On Jun 25, 3:09 pm, nakisa <nakisa.noor...@gmail.com> wrote:
> hi
> i use
>
> CALL RANDOM_NUMBER(m1)
> in program . the problem is that this program always generate the same
> number ! it doesn't mean random number !does it ? so ,i mean it
> doesn't work
It appears that your compiler's random number routine sets its
internal state to the same value whenever a program is run. This state
determines the series of numbers generated by the routine. You need to
set that state - called the "seed" - to a particular value or instruct
that it be set from something like the time of day clock when your
program runs. Check your compiler manual for details. For G95
Call RANDOM_SEED() sets the seed from the time of day.
1. Your compiler may well be different.
2. There are numerous other issues involved in using random numbers in
computer simulations.
HTH
-- e-mail: epc8 at juno dot com
-- elliot
| |
| James Giles 2007-06-25, 10:07 pm |
| Beliavsky wrote:
....
> To get different sets of random variates in each run of the program,
> you can insert a call to the intrinsic subroutine random_seed before
> calling random_number, as in the following program
....
> call random_seed()
> call random_number(xx)
A call to RANDOM_SEED with no arguments does not
guarantee a different sequence with each run of the program.
The standard only says that if no arguments are present
the processor will provide a processor dependent seed.
That could be the same seed each time. Sure, many
implementations provide a new seed each time (probably
based on the system's real-time clock or something).
You have to read the specific compiler's documentation
to find out what RANDOM_SEED does with no arguments.
To guarantee a genuinely new sequence each time, you have
to explicitly provide a unique seed yourself. The proper
call to RANDOM_SEED will be documented in each compiler's
documentation (yes, the proper call is not portable since the
size of the seed array is also implementation dependent).
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| e p chandler 2007-06-25, 10:07 pm |
| On Jun 25, 3:38 pm, nakisa <nakisa.noor...@gmail.com> wrote:
> hi Chris
> the problem is the value of m1 , not it's sign !!
Re: generating random numbers via call random_number(m1), etc.
Back in prehistoric times, some random number routines were SEEDED by
calling them with special values of the argument. For example, in
various dialects of Microsoft BASIC, RND(0) returned the last value
generated, RND(x) produced the next if x is positive but seeded the
generator and then produced the next from that stream if x is
negative.
There are may different ways of writing and calling random number
routines. IIRC, RANDOM_NUMBER() and RANDOM_SEED() are standard
routines in recent Fortran but their internal workings may be
completely different between compilers, versions, vendors, etc.
Good luck.
| |
| Rich Townsend 2007-06-25, 10:07 pm |
| James Giles wrote:
> Beliavsky wrote:
> ...
> ...
>
> A call to RANDOM_SEED with no arguments does not
> guarantee a different sequence with each run of the program.
> The standard only says that if no arguments are present
> the processor will provide a processor dependent seed.
> That could be the same seed each time. Sure, many
> implementations provide a new seed each time (probably
> based on the system's real-time clock or something).
> You have to read the specific compiler's documentation
> to find out what RANDOM_SEED does with no arguments.
>
> To guarantee a genuinely new sequence each time, you have
> to explicitly provide a unique seed yourself. The proper
> call to RANDOM_SEED will be documented in each compiler's
> documentation (yes, the proper call is not portable since the
> size of the seed array is also implementation dependent).
>
I thought the correct size could be determined from a call with the appropriate
argument, no?
| |
| Steven G. Kargl 2007-06-25, 10:07 pm |
| In article <f5ppfr$obn$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
> James Giles wrote:
>
> I thought the correct size could be determined from a call with the
> appropriate argument, no?
yes.
call random_seed(size=n)
allocate(put(n))
put = nrand + 37 * (/ (i - 1, i = 1, n) /)
call random_seed(put=put)
deallocate(put)
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| James Giles 2007-06-26, 4:17 am |
| Steven G. Kargl wrote:
> In article <f5ppfr$obn$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
....
>
> yes.
>
> call random_seed(size=n)
> allocate(put(n))
> put = nrand + 37 * (/ (i - 1, i = 1, n) /)
> call random_seed(put=put)
> deallocate(put)
Well, that satisfies the requirements of the compiler. But,
whether such a simple serial correlation between the elements
of the seed is a good idea depends on the implementation
too. (I assume, since the intend is to get a different seed
for each run, that NRAND is set to something that varies
like a hash of the real time clock or something.)
I still think you're likely better off changing the code to
accomodeate each implementation. Even if that turns out
to have been unnecessary it's best to make a practice of
always making sure. Then again, if you're just gaming
or something, it's merely the appearance of randomness
that's needed and it may not matter whether you do a good
job or not.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| David Flower 2007-06-26, 4:17 am |
| On Jun 25, 8:50?pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> Beliavsky wrote:
>
> ...
>
> ...
>
> A call to RANDOM_SEED with no arguments does not
> guarantee a different sequence with each run of the program.
> The standard only says that if no arguments are present
> the processor will provide a processor dependent seed.
> That could be the same seed each time. Sure, many
> implementations provide a new seed each time (probably
> based on the system's real-time clock or something).
> You have to read the specific compiler's documentation
> to find out what RANDOM_SEED does with no arguments.
>
> To guarantee a genuinely new sequence each time, you have
> to explicitly provide a unique seed yourself. The proper
> call to RANDOM_SEED will be documented in each compiler's
> documentation (yes, the proper call is not portable since the
> size of the seed array is also implementation dependent).
>
> --
> J. Giles
>
> "I conclude that there are two ways of constructing a software
> design: One way is to make it so simple that there are obviously
> no deficiencies and the other way is to make it so complicated
> that there are no obvious deficiencies." -- C. A. R. Hoare
One question:
Is there any compiler that actually provides the same seed each time ?
....and one comment.
The ability to produce the same sequence of random numbers each time
is useful for test purposes. A machine-independent random number
generator that does this was published in A.C.M.Trans. Trans. Math.
Software, 5, #2, 132 (1979).
I will post a copy of my (F77) source if anyone wants it
Dave Flower
| |
| Rich Townsend 2007-06-26, 8:06 am |
| James Giles wrote:
> Steven G. Kargl wrote:
> ...
>
> Well, that satisfies the requirements of the compiler. But,
> whether such a simple serial correlation between the elements
> of the seed is a good idea depends on the implementation
> too. (I assume, since the intend is to get a different seed
> for each run, that NRAND is set to something that varies
> like a hash of the real time clock or something.)
>
> I still think you're likely better off changing the code to
> accomodeate each implementation. Even if that turns out
> to have been unnecessary it's best to make a practice of
> always making sure. Then again, if you're just gaming
> or something, it's merely the appearance of randomness
> that's needed and it may not matter whether you do a good
> job or not.
>
In fact, if I were worried about the 'quality' of the random numbers in any way,
I wouldn't use the compiler's RNG at all. I'd go instead with something that's
been validated, like one of the routines in Numerical Recipes.
| |
| Dick Hendrickson 2007-06-26, 10:06 pm |
| David Flower wrote:
> On Jun 25, 8:50?pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
>
> One question:
>
> Is there any compiler that actually provides the same seed each time ?
>
Yes, at least 10 or so years ago there were several. My test suite
actually has two forms of a random number tester. One assumes that the
seed will be the same each time, the other that it will be different.
The vendor picks whichever one they want and then the suite tests for
consistency.
Dick Hendrickson
> ...and one comment.
>
> The ability to produce the same sequence of random numbers each time
> is useful for test purposes. A machine-independent random number
> generator that does this was published in A.C.M.Trans. Trans. Math.
> Software, 5, #2, 132 (1979).
> I will post a copy of my (F77) source if anyone wants it
>
> Dave Flower
>
| |
| Steven G. Kargl 2007-06-26, 10:06 pm |
| In article <f5qrsq$45n$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
> James Giles wrote:
I never claimed the above code was a unversal solution nor
of some high quality. It simply answers Rich's question.
I guess I could have said 'See Section 13.7.95.'
[color=darkred]
nrand can be user input because sometimes you do want the
same sequence of PRN.
[color=darkred]
I suppose I could have shown
program a
integer n
integer, allocatable :: m(:)
character, allocatable :: val(:)
call random_seed(size=n)
print *, n
allocate(m(n), val(4*n))
open(unit=10, file='/dev/urandom')
do i=1,4*n
read(10,*) val(i)
end do
m = transfer(val, m)
print *, m
deallocate(m,val)
end program a
% gfortran -o z a.f90
% ./z
8
1023967029 31479249 -560538552 -1898123915 397582077 2098421774
2133122842 1604701863
But, James would complain that /dev/urandom isn't portable, and a
multiplicative factor of 4 assumes a 32-bit integer.
PS: yes, gfortran's random_number algorithm uses 8 seeds, so using
the time of day to seed the PRNG isn't necessary sufficient.
[color=darkred]
> In fact, if I were worried about the 'quality' of the random numbers
> in any way, I wouldn't use the compiler's RNG at all. I'd go instead
> with something that's been validated, like one of the routines in
> Numerical Recipes.
Why not test the compiler's PRNG? Or, read the source code for the
compiler's PRNG (oh yeah, some vendors don't supply code)? I would
assume that you would test a PRNG of any other pedigree.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Steven G. Kargl 2007-06-26, 10:06 pm |
| In article <1182847137.684578.83780@n60g2000hse.googlegroups.com>,
David Flower <DavJFlower@AOL.COM> writes:
>
> One question:
>
> Is there any compiler that actually provides the same seed each time ?
Yes. gfortran has a default set of seeds. A call ro random_seed()
without arguments resets the PRNG with that default set.
program a
real :: m(4)
call random_number(m)
print *, m
call random_seed()
call random_number(m)
print *, m
end program a
% gfortran -o z h.f90
% ./z
0.9975595 0.5668247 0.9659153 0.7479277
0.9975595 0.5668247 0.9659153 0.7479277
> ...and one comment.
>
> The ability to produce the same sequence of random numbers each time
> is useful for test purposes.
And, this is the reason that gfortran was designed this way. It
comes down to one of two choices if random_seed is not called
prior to a call to random_number: 1) Use a default set of seeds
that starts the PRNG on a known sequence, or 2) Use a system-dependent
seemingly random set of seeds to generate different sequences.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Pierre Asselin 2007-06-26, 10:07 pm |
| Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
> In article <f5ppfr$obn$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
[color=darkred]
> yes.
> call random_seed(size=n)
> allocate(put(n))
> put = nrand + 37 * (/ (i - 1, i = 1, n) /)
> call random_seed(put=put)
> deallocate(put)
Yes, but there is no way of knowing what values are safe to place
in the put(:) array. I know :-( The only guarantee is that an
array filled with random_seed(get=...) can be (put=...) back
and resets the sequence to the same point.
--
pa at panix dot com
|
|
|
|
|