On Fri, 08 Aug 2008 00:08:48 -0700, james.annan@
gmail.com wrote:
> On Aug 8, 2:39 pm, Gib Bogle
auckland.no.spam.ac.nz> wrote:>> Richard Maine wrote:
>>> Howard Jaegermeister wrote:
>>
>>>> integer, dimension(6)::A
>>>> integer:: b
>>>> real:: harvest
>>>> A = 0
>>>> call random_number(harvest)
>>>> b = floor(harvest*6)
>>
>>>> print *, harvest, b
>>
>>>> end program
>>
>>>> I would expect repeat to be a real pseudorandom on the open unit
>>>> interavl and b to be the result. Got nothing. Thanks for help,
>>
>>> A little more precision in the question would help. In particular,
>>> what do you mean by "got nothing." I can't sensibly interpret that in
>>> this context. The closest I can come to a literal interpretation
>>> would be that the program had no output at all, which could suggest
>>> any of several things; I'd need much more detail on how you tried to
>>> build and run the program to offer much help on that, as that would
>>> probably have more to do with the build/run process than with the
>>> code.
>>
>>> Or maybe "nothing" means zeros. That wouldn't be too surprising for
>>> b, but it wouldn't make much sense for harvest. I just compiled the
>>> code, exactly as is using g95 on this Mac, and got the result
>>
>>> 0.9839003 5
>>
>> It's surprising to me that the default seed values with g95 on the Mac
>> and using Cygwin are the same. On second thoughts I shouldn't be
>> surprised, I guess that's a useful feature.
>
> If I may just interject, I would suggest that it is safer to not use the
> in-built PRNG, but supply your own (which can easily be found on the
> web).
>
> I've wasted quite a lot of time recently trying to work out why some
> legacy fortran was crashing on various (modern) architectures and
> compilers but not others. It turns out that the random number generator
> was returning the same number every time (for some compilations), and
> unfortunately the program didn't like that at all. Of course for trivial
> applications where this sort of problem would be immediately obvious,
> it's not such an issue. But it would seem good practice to avoid the
> possibility as a matter of course.
>
> James
I noticed the same thing, but it took a while for it to sink in with me
(bit of a story too). I am **very much** in favor of .983 being the
first pseudo-random.
The clock will do nicely for my purpose:
SUBROUTINE init_random_seed()
INTEGER :: i, n, clock
INTEGER, DIMENSION(:), ALLOCATABLE :: seed
CALL RANDOM_SEED(size = n)
ALLOCATE(seed(n))
CALL SYSTEM_CLOCK(COUNT=clock)
seed = clock + 37 * (/ (i - 1, i = 1, n) /)
CALL RANDOM_SEED(PUT = seed)
DEALLOCATE(seed)
END SUBROUTINE
I simply don't understand this syntax. I'm keen on parts of it. 37 is a
sexy prime, one of my uncle Charles', algebraist, top ten numbers.
Indeed, the highest one.
I don't know what's being allocated here:
ALLOCATE(seed(n))
??
--
Howard
