------- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-09-15 03:43 -------
(In reply to comment #2)
> >
> > > I agree that the current gfortran's behaviour is standard conforming.
> >
> > Enough said.
> >
> > > But it is counter intuitive.
> >
> > It is counter intuitive to you not me.
> >
>
> Dont know what to say. Well if the original authors want it that way
> there is really nothing I can do about it.
(1) Supply a patch if you want something else.
(2) There are several real bugs that need squishing. The current behavior
conforms to the standard. We have limited time and resources.
(3) Even if gfortran changed its behavior, you are depending
on processor-dependent behavior. Are you going to ask
Absoft (and ever other vendor) to change their random_seed()
behavior to suit your needs.
(4) A portable solution exist. I hacked this up in about 1 minute.
I'm sure your can wrap this in a subroutine, enhance it, and
call that subroutine instead of random_seed().
integer size, values(8)
real, allocate :: put(:)
call random_seed(size=size)
allocate(put(size))
call date_and_time(values=values)
if (any(values) == 0) values = 7
if (size <= 8) then
put(1:size) = values(1:size)
else
put = 10
put(1:8) = values
end if
call random_seed(put=put)
deallocate(put)
> Would it atleast be possible to implement it as an extension?
> Something like if the user gives an option in the compiling command,
> then the random numbers generated across different runs will be
> different.
I believe you can do this on mainline. The patch to pass compile time flags
to the runtime library may not be available in 4.0.2. I'll changed your
PR to an enhancement request when I get a chance (although I doubt anyone
will get to this in the near future).
> Sorry that was my bad. Absoft's and gfortran's behaviour are indeed
> the same. But g95 and intel's behaviour are different than gfortran
> (in this issue).
Clearly, you are looking at processor-dependent behavior. I advocate
that you investigate the portable solution that I've outlined above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
