seed problem in a random number generator subroutine

I have a random digit number generator subroutine and a seed file
When the seed file number dseed=1620617369.0000, the simulation stopped
running.
Does anyone know what happened and how to fix it?
I wonder if it is the seed value problem or it is something else.
Thank you very much!






double precision dseed
double precision aa,mm
real zz(2),uu(2)
common/ranparm/aa,mm
common/ramsave/zz
mm=dble((2.0d0)**31-1.d0)
aa=dble((7.0d0)**5)

open (22,file='seed.txt')
read (22,*)dseed
rewind(22)

call digran(dseed,p,q,y)

write(22,*)dseed
close(22)
end

c---------------------------------
c generates n random numbers from U(0,1),
c and stores them in array u(n).
subroutine rangen(dseed,n,u)
real u(n)
double precision dseed,aa,mm
common/ranparm/aa,mm

do 10 i=1,n
dseed=dmod(aa*dseed,mm)
u(i)=sngl(dseed/mm)
10 continue
c---------------------------------------
return
end

c --------------------------------------------------
c generate random digital number between p and q
c p < q
c output =iy
c --------------------------------------------------
subroutine digran(dseed,p,q,iy)
double precision dseed
real y
real p,q
integer iy

call rangen(dseed,1,y)
iy=p + nint(y* (q-p+1.))

if (iy > q) then
iy= q
else if (iy < p) then
iy=p
endif

return
end

A question and a couple of style comments.

Dick Hendrickson

PCAT wrote:
> I have a random digit number generator subroutine and a seed file
> When the seed file number dseed=1620617369.0000, the simulation stopped
> running.
How did it stop? Was there an error message?

> Does anyone know what happened and how to fix it?
> I wonder if it is the seed value problem or it is something else.
> Thank you very much!
>
>
>
>
>
>
> double precision dseed
> double precision aa,mm
> real zz(2),uu(2)
> common/ranparm/aa,mm
> common/ramsave/zz
> mm=dble((2.0d0)**31-1.d0)
> aa=dble((7.0d0)**5)
>
> open (22,file='seed.txt')
> read (22,*)dseed
> rewind(22)
>
> call digran(dseed,p,q,y)
Here y is a single precision real variable, in digran it's
declared integer.

>
> write(22,*)dseed
> close(22)
> end
>
> c---------------------------------
> c generates n random numbers from U(0,1),
> c and stores them in array u(n).
> subroutine rangen(dseed,n,u)
> real u(n)
> double precision dseed,aa,mm
> common/ranparm/aa,mm
>
> do 10 i=1,n
> dseed=dmod(aa*dseed,mm)
> u(i)=sngl(dseed/mm)
> 10 continue
> c---------------------------------------
> return
> end
>
> c --------------------------------------------------
> c generate random digital number between p and q
> c p < q
> c output =iy
> c --------------------------------------------------
> subroutine digran(dseed,p,q,iy)
> double precision dseed
> real y
> real p,q
> integer iy
>
> call rangen(dseed,1,y)
Here y is a variable, in rangen it's an array.

> iy=p + nint(y* (q-p+1.))
>
> if (iy > q) then
> iy= q
> else if (iy < p) then
> iy=p
> endif
>
> return
> end
>

Dick Hendrickson wrote:
> A question and a couple of style comments.
>
> Dick Hendrickson
>
> PCAT wrote:
> > I have a random digit number generator subroutine and a seed file
> > When the seed file number dseed=1620617369.0000, the simulation stopped
> > running.
> How did it stop? Was there an error message?
It didnot show any error message. I also ask the program to write the
seconds it takes to run the program. The cursor just stopped there and
didnot get to the next step.

> > Does anyone know what happened and how to fix it?
> > I wonder if it is the seed value problem or it is something else.
> > Thank you very much!
> >
> >
> >
> >
> >
> >
> > double precision dseed
> > double precision aa,mm
> > real zz(2),uu(2)
> > common/ranparm/aa,mm
> > common/ramsave/zz
> > mm=dble((2.0d0)**31-1.d0)
> > aa=dble((7.0d0)**5)
> >
> > open (22,file='seed.txt')
> > read (22,*)dseed
> > rewind(22)
> >
> > call digran(dseed,p,q,y)
> Here y is a single precision real variable, in digran it's
> declared integer.
HI, y is a real number, in digran, it is still real number , the
integer is for iy.
> >
> > write(22,*)dseed
> > close(22)
> > end
> >
> > c---------------------------------
> > c generates n random numbers from U(0,1),
> > c and stores them in array u(n).
> > subroutine rangen(dseed,n,u)
> > real u(n)
> > double precision dseed,aa,mm
> > common/ranparm/aa,mm
> >
> > do 10 i=1,n
> > dseed=dmod(aa*dseed,mm)
> > u(i)=sngl(dseed/mm)
> > 10 continue
> > c---------------------------------------
> > return
> > end
> >
> > c --------------------------------------------------
> > c generate random digital number between p and q
> > c p < q
> > c output =iy
> > c --------------------------------------------------
> > subroutine digran(dseed,p,q,iy)
> > double precision dseed
> > real y
> > real p,q
> > integer iy
> >
> > call rangen(dseed,1,y)
> Here y is a variable, in rangen it's an array.
This part I tried to fix it. If I modify the y as y(1) in digran, then
there will be compiling error: Error: The shapes of the array
expressions do not conform. [IY]
iy=p + nint(y* (q-p+1.))
--------^
I don't know a good way to fix it.
However these two subroutines works well on my other programs. I don't
know if there is anything I should fix.
Thank you very much.
>
> > iy=p + nint(y* (q-p+1.))
> >
> > if (iy > q) then
> > iy= q
> > else if (iy < p) then
> > iy=p
> > endif
> >
> > return
> > end
> >

Dick Hendrickson wrote:
> A question and a couple of style comments.
>
> Dick Hendrickson
>
> PCAT wrote:
> > I have a random digit number generator subroutine and a seed file
> > When the seed file number dseed=1620617369.0000, the simulation stopped
> > running.
> How did it stop? Was there an error message?
It didnot show any error message. I also ask the program to write the
seconds it takes to run the program. The cursor just stopped there and
didnot get to the next step.

> > Does anyone know what happened and how to fix it?
> > I wonder if it is the seed value problem or it is something else.
> > Thank you very much!
> >
> >
> >
> >
> >
> >
> > double precision dseed
> > double precision aa,mm
> > real zz(2),uu(2)
> > common/ranparm/aa,mm
> > common/ramsave/zz
> > mm=dble((2.0d0)**31-1.d0)
> > aa=dble((7.0d0)**5)
> >
> > open (22,file='seed.txt')
> > read (22,*)dseed
> > rewind(22)
> >
> > call digran(dseed,p,q,y)
> Here y is a single precision real variable, in digran it's
> declared integer.
HI, y is a real number, in digran, it is still real number , the
integer is for iy.
> >
> > write(22,*)dseed
> > close(22)
> > end
> >
> > c---------------------------------
> > c generates n random numbers from U(0,1),
> > c and stores them in array u(n).
> > subroutine rangen(dseed,n,u)
> > real u(n)
> > double precision dseed,aa,mm
> > common/ranparm/aa,mm
> >
> > do 10 i=1,n
> > dseed=dmod(aa*dseed,mm)
> > u(i)=sngl(dseed/mm)
> > 10 continue
> > c---------------------------------------
> > return
> > end
> >
> > c --------------------------------------------------
> > c generate random digital number between p and q
> > c p < q
> > c output =iy
> > c --------------------------------------------------
> > subroutine digran(dseed,p,q,iy)
> > double precision dseed
> > real y
> > real p,q
> > integer iy
> >
> > call rangen(dseed,1,y)
> Here y is a variable, in rangen it's an array.
This part I tried to fix it. If I modify the y as y(1) in digran, then
there will be compiling error: Error: The shapes of the array
expressions do not conform. [IY]
iy=p + nint(y* (q-p+1.))
--------^
I don't know a good way to fix it.
However these two subroutines works well on my other programs. I don't
know if there is anything I should fix.
Thank you very much.
>
> > iy=p + nint(y* (q-p+1.))
> >
> > if (iy > q) then
> > iy= q
> > else if (iy < p) then
> > iy=p
> > endif
> >
> > return
> > end
> >

I'll first note that you would probably be better off to use either the
random number generator that comes with your compiler (I didn't see you
mention what compiler you were using, but as of f90, the standard
requires the compiler to have one) or a 3rd party library one instead of
trying to craft your own. It isn't as though the one you have does
anything special.

PCAT <pcatchen@gmail.com> wrote:
> Dick Hendrickson wrote:
> > PCAT wrote:
> > > call digran(dseed,p,q,y)
> > Here y is a single precision real variable, in digran it's
> > declared integer.
> HI, y is a real number, in digran, it is still real number , the
> integer is for iy.

Dick is a pretty bright guy. Not that he can't overlook things on
occasion, like all of us, but he's right a lot more often than not...
including here.

> > > subroutine digran(dseed,p,q,iy)
> > > double precision dseed
> > > real y
> > > real p,q
> > > integer iy

The 4th dummy argument of digran is integer, as seen above. It makes no
difference what it is named; it is the 4th argument and has a type that
disagrees with the 4th argument in the call. The y in digran has nothing
to do with the question. I might suggest that it is confusing to use the
same name for different things in different scopes; it appears to have
confused you here, illustrating the point.

> > > call rangen(dseed,1,y)
> > Here y is a variable, in rangen it's an array.
> This part I tried to fix it. If I modify the y as y(1) in digran, then
> there will be compiling error: Error: The shapes of the array
> expressions do not conform. [IY]
> iy=p + nint(y* (q-p+1.))
> --------^
> I don't know a good way to fix it.

That's because you are using it as a scalar, so you can't just change
its declaration to be an array. You have to be consistent. If it is to
be an array, declare it as one and use it that way. If it is a scalar,
likewise be consistent.

Note that an array of size 1 is not the same thing as a scalar. If you
want a scalar that is the first element, that would be y(1) rather than
y; they are not the sam ething even if y has only one element.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard E Maine <nospam@see.signature> wrote:
> I'll first note that you would probably be better off to use either the
> random number generator that comes with your compiler (I didn't see you
> mention what compiler you were using, but as of f90, the standard
> requires the compiler to have one) or a 3rd party library one instead of
> trying to craft your own. It isn't as though the one you have does
> anything special.

or for a third choice, find a reliable reference on constructing
random number generators. Knuth, "The art of computer programming",
volume 2, is a popular reference.

(snip)
>> > > call digran(dseed,p,q,y)
>> > Here y is a single precision real variable, in digran it's
>> > declared integer.
>> HI, y is a real number, in digran, it is still real number , the
>> integer is for iy.

(snip regarding the wrong type of the fourth argument to digran)

Also, in the example given the p and q arguments to digran are
not initialized before the call.

(snip)

> That's because you are using it as a scalar, so you can't just change
> its declaration to be an array. You have to be consistent. If it is to
> be an array, declare it as one and use it that way. If it is a scalar,
> likewise be consistent.

> Note that an array of size 1 is not the same thing as a scalar. If you
> want a scalar that is the first element, that would be y(1) rather than
> y; they are not the sam ething even if y has only one element.

I don't remember if this is supposed to work, or not.

It is obviously legal to pass an array element to a scalar dummy
argument, and it is legal to pass an array element to an assumed
size array dummy, where you get the part of the array starting with
the element passed. Given those, it is likely that passing a scalar
to an assumed size dummy dimensioned one will work, even if the
standard doesn't require it. I am not sure right now what the
standard says. (I will look it up later.)

-- glen

glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:

> it is likely that passing a scalar
> to an assumed size dummy dimensioned one will work, even if the
> standard doesn't require it. I am not sure right now what the
> standard says. (I will look it up later.)

It is not standard and there do exist compilers that reject it in some
cases. (The case where the scalar in question is an array element is a
special case, which is allowed, but a general scalar is not; in fact, in
Fortran 77 an array element didn't even count as the same kind of thing
as a scalar variable - it was a separate category all of its own).

Yes, it will happen to work anyway in most cases, particularly when the
subroutine is in a separate source file from the call so that the
compiler probably won't notice. I have personally had compilers reject
such code when they noticed, though. In fact, I recall one case of a bug
in one of my programs that lay undetected for an awfully long time. Part
of the reason it stayed undetected is that it worked as I intended
wherever I had tried it... until the day that a compiler complained
about it, prompting me to notice my error.

It was in a wrapper subroutine, which was supposed to do something like
(probably with other arguments also, but this is the critical part).

subroutine wrapper(x)
real x(*)
call sub(x)
end

I had accidentally omitted the declaration (this was from days before
implicit none was standard) so my x was a scalar, but was passed to sub,
which expectd an array. I'm sure that was a completelly accidental
omission on my part, rather than an attempt to do something strange. As
long as the arguments were passed by addess, it worked anyway, but it
was not standard.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard E Maine <nospam@see.signature> wrote:
(snip about mixing scalar and array arguments/dummies)

> It was in a wrapper subroutine, which was supposed to do something like
> (probably with other arguments also, but this is the critical part).

> subroutine wrapper(x)
> real x(*)
> call sub(x)
> end

Without the real x(*) on a system that used call by value result
for scalars this wouldn't work for a arrays, but it should work for
call by reference on most systems that I know about.

There are stories about old C code, (mostly before ANSI C)
that would use int variables to in place of your x, to pass
a pointer through to another subroutine. (I believe older
compilers allowed implicit declaration for int variables.)
It usually works if sizeof(int)==sizeof(char*), which was
true on many C compilers.

For C, a pointer to a scalar will always work in place
of an array dimensioned one. It never works in Java.

-- glen

On Thu, 14 Sep 2006 23:43:03 +0000 (UTC), glen herrmannsfeldt
<gah@seniti.ugcs.caltech.edu> wrote:

> Richard E Maine <nospam@see.signature> wrote:
> (snip about mixing scalar and array arguments/dummies)
>
> > It was in a wrapper subroutine, which was supposed to do something like
> > (probably with other arguments also, but this is the critical part).
>
> > subroutine wrapper(x)
> > real x(*)
> > call sub(x)
> > end
>
> Without the real x(*) on a system that used call by value result
> for scalars this wouldn't work for a arrays, but it should work for
> call by reference on most systems that I know about.
>
> There are stories about old C code, (mostly before ANSI C)
> that would use int variables to in place of your x, to pass
> a pointer through to another subroutine. (I believe older
> compilers allowed implicit declaration for int variables.)

"Classical" C (K&R1) allowed _C parameters_ (= Ftn dummy args) to be
implicitly int, and C89 retained this. C99, and C++98, deleted it.

K&R1 and C89 also allow _function_ names to be implicitly declared (as
taking old-style arguments and returning int). C99 and C++98 do not.

And the former but again not the latter allow a variable declaration
to omit the type and default to int:
/* older C */ static x; /* is an int */
and a function definition to omit all specifiers ditto:
/* older C */ f (x) { /* function, of int x, returning int */ }

No C has ever allowed a variable's declaration to be entirely
implicit. I don't believe even (typeless) B or BCPL did.

> It usually works if sizeof(int)==sizeof(char*), which was
> true on many C compilers.
>
> For C, a pointer to a scalar will always work in place
> of an array dimensioned one. It never works in Java.
>
Of course in Java 'array' is actually its own object (in the OO sense)
type, not just an aggregate of the element type.

- David.Thompson1 at worldnet.att.net