difficulty with random_number()
nakisa
I need create random number and write
call random_number(test)
the strange thing is as much as I run the code , it returns the same
number.
I use f95 in ubunutu .
Does anybody know where is my mistake ?
best,nakisa
kar...@comcast.net
You need to show the actual code or at least a small testcase.
--
steve
nakisa
please look at this sample :
--------------------------------------------
program small
implicit none
real test
call random_number(test)
print *,"test = ", test
end program small
-----------------------------------
and my machine gives
test = 0.9975595
every time that I run it !
nakisa
kar...@comcast.net
You need to seed the random number generator.
By default, some Fortran compilers will use a given
set of seeds if you do not explicitly seed the
generator. Other compilers will automatically seed
the generator with some "random" seeds for you.
--
steve
Dan Nagle
On 2009-03-14 14:10:09 -0400, nakisa <nakisa....@gmail.com> said:
> and my machine gives
> test = 0.9975595
> every time that I run it !
Are you setting the seed?
--
Cheers!
Dan Nagle
nakisa
program small
implicit none
real test
call random_seed()
call random_number(test)
print *,"test = ", test
end program small
-----------------------------------
but adding random_seed doesn't change the situation, the answer is the
same with previous one .
nakisa
dpb
> The seed for the pseudorandom number generator used by RANDOM_NUMBER
> can be set or queried with RANDOM_SEED. If RANDOM_SEED is not used,
> the processor sets the seed for RANDOM_NUMBER to a processor-dependent value.
I haven't the Standard in front of me to check whether it says whether
the default initial seed is supposed to be reproducible or not but it
wouldn't be surprising if it does to allow verification of code
operation outside the randomness portion of the algorithm. If it
doesn't specify specifically, then it would be implementation-dependent
and either choice valid.
Either way, try RANDOM_SEED first and see if that doesn't solve your
difficulties.
--
James Van Buskirk
news:8a834cf2-01d7-470d...@t3g2000yqa.googlegroups.com...
> program small
> implicit none
The above works with almost every compiler except gfortran. For an
example of how to achieve what you want with gfortran, look up the
RANDOM_SEED intrinsic in the gfortran manual.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
dpb
Read documentation for the routines for the specific compiler. Symptoms
would seem to indicate the call w/ missing value to RANDOM_SEED is the
same default action as not calling it.
See other note regarding I'm not sure what Standard says or if it is
defined as compiler/implementation specific (would be my guess w/o
looking it up).
--
Richard Maine
> I haven't the Standard in front of me to check whether it says whether
> the default initial seed is supposed to be reproducible or not but it
> wouldn't be surprising if it does to allow verification of code
> operation outside the randomness portion of the algorithm. If it
> doesn't specify specifically, then it would be implementation-dependent
> and either choice valid.
The standard is, unfortunately, completely ambiguous on the point. I
recall the author of the words in question explaining what he meant to
say, but his intention never managed to make it into his written words.
I take that as an object lesson in standing back and reading proposal
material instead of focussing on detailed wording so much that one
overlooks the simple basics and overall picture.
I think he was trying to argue that an interp should establish his
unstated intention. However, that was after there were multiple existing
implementations that would have been invalidated by the proposed interp,
all with justifications of why those particular ways were best, causing
significant resistance. The unexpressed intention of a single person
doesn't necessarily constitute evidence of the majority intent of the
committee, much less a formal standard. I'm afraid I've actually
forgotten what he said his intention was... because it no longer
matters. The standard just stands mute on the question, significantly
detracting from the portable utility of the feature.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
kar...@comcast.net
Please read the description of random_seed.
"If no argument is present, the processor assigns a
processor-dependent value to the seed."
You have the same effect as if you don't call random_seed() at all.
program small
implicit none
real test
integer i, j, val(8)
integer, allocatable :: seeds(:)
call random_seed(size=j)
allocate(seeds(j))
! There are much better choices.
call date_and_time(values=val)
print '(8(I0,1X))', val
seeds = (/ (val(8), i = 1, j) /)
call random_seed(put=seeds)
kar...@comcast.net
wrote:
> "nakisa" <nakisa.noor...@gmail.com> wrote in message
>
> news:8a834cf2-01d7-470d...@t3g2000yqa.googlegroups.com...
>
> > at first I guess maybe the error was in omitting random_seed
> > program small
> > implicit none
> > real test
> > call random_seed()
> > call random_number(test)
> > print *,"test = ", test
> > end program small
> > -----------------------------------
> > but adding random_seed doesn't change the situation, the answer is the
> > same with previous one .
>
> The above works with almost every compiler except gfortran.
The above works with gfortran, too. Of course, one needs to
define "works".
:-)
--
steve
dpb
> dpb <no...@non.net> wrote:
>
>> I haven't the Standard in front of me to check whether it says whether
>> the default initial seed is supposed to be reproducible or not but it
>> wouldn't be surprising if it does to allow verification of code
>> operation outside the randomness portion of the algorithm. If it
>> doesn't specify specifically, then it would be implementation-dependent
>> and either choice valid.
>
> The standard is, unfortunately, completely ambiguous on the point. I
> recall the author of the words in question explaining what he meant to
> say, but his intention never managed to make it into his written words.
> I take that as an object lesson in standing back and reading proposal
> material instead of focussing on detailed wording so much that one
> overlooks the simple basics and overall picture.
Re: the followup posting is the Standard any less ambiguous on the
default for RANDOM_SEED()? I gather probably not from James' response.
I don't recall I've used the newer intrinsics since all the RNG-related
codes I've worked on have always used their own packages anyway so I'm
not familiar w/ the behavior even on the compilers I've used and the
most frequently used doesn't specifically say, either (I gather probably
remaining as ambiguous as the Standard from whence it came :) ).
--
Richard Maine
> Re: the followup posting is the Standard any less ambiguous on the
> default for RANDOM_SEED()?
I don't think so. I recall some debate about whether "processor
dependent" meant that it was just a single number, whose value was
processor dependent, or whether that meant the processor could choose a
different number each time. I don't recall the answer, if any. Sure
would have been nicer if the standard actually said instead of leaving
people to have to interpret such nuances of wording. It isn't as if
there is actually a rule against specifying such things clearly in the
standard.
Gib Bogle
That isn't a difficulty, it's a desired behaviour. You want the random
number generator to return the same sequence of random numbers every
time you execute a program with the same seed value. Since you don't
specify a seed, the compiler is setting one for you, the same every time
the program executes. Your test program generates only one number, so
it is the same for every run. If you put the random_number() line in a
loop, you'll see that it generates a stream of different numbers.
For some purposes it is useful to specify a starting seed value. The
statement above still applies: every run using the same specified seed
value will generate the same sequence, meaning that you can rerun your
program, with supposedly random effects, and get exactly the same
results. Very useful. To get a different realization you just change
the seed.
glen herrmannsfeldt
> dpb <no...@non.net> wrote:
>> Re: the followup posting is the Standard any less ambiguous on the
>> default for RANDOM_SEED()?
> I don't think so. I recall some debate about whether "processor
> dependent" meant that it was just a single number, whose value was
> processor dependent, or whether that meant the processor could choose a
> different number each time.
It might not be so easy for some to supply a different number
each time. Since the standard has DATE_AND_TIME, one could
use that but you can call RANDOM_SEED() many times in one
second. Also, it seems that the standard doesn't require
a clock anyway.
-- glen
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > dpb <no...@non.net> wrote:
>
> >> Re: the followup posting is the Standard any less ambiguous on the
> >> default for RANDOM_SEED()?
>
> > I don't think so. I recall some debate about whether "processor
> > dependent" meant that it was just a single number, whose value was
> > processor dependent, or whether that meant the processor could choose a
> > different number each time.
>
> It might not be so easy for some to supply a different number
> each time.
That was not the issue at all. That's pretty much a non-issue in terms
of the standard. It would be trivial to just say that it did not need to
be the same each time, perhaps with a suggestion that the processor
might make it different if practical.
No, the only issue was just plain sloppy writing that failed to say.
Nothing more complicated than that.
robin
Put the CALL and PRINT inside a loop and see what happens.
Dave Seaman
There is not likely to be a need to call RANDOM_SEED() more than once in
a given program run, other than to restore a previously saved seed.
--
Dave Seaman
Third Circuit ignores precedent in Mumia Abu-Jamal ruling.
<http://www.indybay.org/newsitems/2008/03/29/18489281.php>
glen herrmannsfeldt
(snip on RANDOM_SEED, I wrote)
>> It might not be so easy for some to supply a
>> different number each time.
> That was not the issue at all. That's pretty much a non-issue in terms
> of the standard. It would be trivial to just say that it did not need to
> be the same each time, perhaps with a suggestion that the processor
> might make it different if practical.
Yes that would have worked, though it really isn't much
help to someone actually using it. Well, overall I don't
like the way RANDOM_SEED works. Many RNGs have requirements
on what makes a 'good' seed. It would be nice to be able to
supply a single INTEGER such that RANDOM_SEED would select
a good seed based on that. Instead, you have to supply
N integers. RANDOM_SEED has to be able to make a good
seed out of those N integers, in addition to be able to
accept a seed previously obtained from RANDOM_SEED.
The restoring of a previously stored seed should
be a separate operation from seeding from outside
entropy (randomness). The latter should allow any
number of words of input, from one, to N or more.
> No, the only issue was just plain sloppy writing that
> failed to say. Nothing more complicated than that.
Well, that too.
-- glen
glen herrmannsfeldt
> There is not likely to be a need to call RANDOM_SEED() more than once in
> a given program run, other than to restore a previously saved seed.
That is true, but when calling it the first time it could be
using a previously stored seed (possibly written to disk), or
new seed data.
-- glen
Larry Gates
From Andy:
subroutine init_seed()
integer :: n, ival(8), v(3), i
integer, allocatable :: seed(:)
call date_and_time(values=ival)
v(1) = ival(8) + 2048*ival(7)
v(2) = ival(6) + 64*ival(5) ! value(4) isn't really 'random'
v(3) = ival(3) + 32*ival(2) + 32*8*ival(1)
call random_seed(size=n)
allocate(seed(n))
call random_seed() ! Give the seed an implementation-dependent kick
call random_seed(get=seed)
do i=1, n
seed(i) = seed(i) + v(mod(i-1, 3) + 1)
enddo
call random_seed(put=seed)
deallocate(seed)
end subroutine
--
larry gates
I'll say it again for the logic impaired.
-- Larry Wall
nakisa
why you allocate "seeds(j)" and then call "random_seed(put=seeds) "??
best,nakisa
kar...@comcast.net
random_seed() has three arguments. SIZE allows you to determine
the number of seed values you need. PUT takes an array of seed
values. GET returns the current seed values.
program testing
integer, allocatable :: seeds(:)
integer num,i
random_seed(size=num) ! Determine number of seeds.
allocate(seeds(num)) ! Allocate an array for seeds.
random_seed(get=seeds) ! Get the current seeds.
print *, seeds ! Print current seeds.
seeds =(/(i,i=1,num)/) ! Fill array with simple set of seeds
random_seed(put=seeds) ! Seed the prng with the new set of seeds.
random_seed(get=seeds) ! Get the new seeds as a check.
print *, seeds ! Print current seeds.
end program testing
kar...@comcast.net
Of course, I should have coffee before writing a program off the top
of head.
s/random_seed/call random_seed/g
--
steve
robin
> Richard Maine <nos...@see.signature> wrote:
> (snip on RANDOM_SEED, I wrote)
>
> >> It might not be so easy for some to supply a
> >> different number each time.
>
> > That was not the issue at all. That's pretty much a non-issue in terms
> > of the standard. It would be trivial to just say that it did not need to
> > be the same each time, perhaps with a suggestion that the processor
> > might make it different if practical.
>
> Yes that would have worked, though it really isn't much
> help to someone actually using it. Well, overall I don't
> like the way RANDOM_SEED works. Many RNGs have requirements
> on what makes a 'good' seed. It would be nice to be able to
> supply a single INTEGER such that RANDOM_SEED would select
> a good seed based on that. Instead, you have to supply
> N integers.
N can equal 1, thus a single integer.
Or, if you want it simple, none at all.
Franken Sense
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message news:gpk28b$s73$1...@naig.caltech.edu...
>> Richard Maine <nos...@see.signature> wrote:
>> (snip on RANDOM_SEED, I wrote)
>>
>>>> It might not be so easy for some to supply a
>>>> different number each time.
>>
>>> That was not the issue at all. That's pretty much a non-issue in terms
>>> of the standard. It would be trivial to just say that it did not need to
>>> be the same each time, perhaps with a suggestion that the processor
>>> might make it different if practical.
>>
>> Yes that would have worked, though it really isn't much
>> help to someone actually using it. Well, overall I don't
>> like the way RANDOM_SEED works. Many RNGs have requirements
>> on what makes a 'good' seed. It would be nice to be able to
>> supply a single INTEGER such that RANDOM_SEED would select
>> a good seed based on that. Instead, you have to supply
>> N integers.
>
> N can equal 1, thus a single integer.
> Or, if you want it simple, none at all.
W/e.
This is a good seed:
contains
subroutine init_seed()
integer :: n, ival(8), v(3), i
integer, allocatable :: seed(:)
call date_and_time(values=ival)
v(1) = ival(8) + 2048*ival(7)
v(2) = ival(6) + 64*ival(5) ! value(4) isn't really 'random'
v(3) = ival(3) + 32*ival(2) + 32*8*ival(1)
call random_seed(size=n)
allocate(seed(n))
call random_seed() ! Give the seed an implementation-dependent kick
call random_seed(get=seed)
do i=1, n
seed(i) = seed(i) + v(mod(i-1, 3) + 1)
enddo
call random_seed(put=seed)
deallocate(seed)
end subroutine
Tja.
--
Frank
Mistakes are a part of being human. Appreciate your mistakes for what they
are: precious life lessons that can only be learned the hard way. Unless
it's a fatal mistake, which, at least, others can learn from.
~~ Al Franken,