Even though the RAN is an extension, it is stopping me to compile some fortran 90 code which I got from someone. module Global implicit none save integer :: iseed end module Global subroutine update(ntimes) use Global implicit none integer i,ntimes i = ran(iseed) return end
Really everywhere I looked, the other compilers suggest that RAN is not an intrinsic but a function.
Confirmed, this is an alpha extension to the language.
So what does RAN(iseed) do? Return a random integer? I think it would be straightforward to implement, but I'm not sure I know what it is meant to do precisely.
Are there any further details on what RAN() is suppose to do? I've implemented G77's irand() function, and I suspect we can map RAN() to irand(). If there is no additional info, this bug report should be closed.
Read http://docs.hp.com/cgi-bin/doc3k/B3150190021.12118/219
Well, I read the URL. It is identical to the RAND() I implemented. http://gcc.gnu.org/ml/gcc-patches/2004-05/msg02016.html Add a "make_alias("ran");" to intrinsic.c after the declaration of "rand". Now, back to your code snippet. "i = ran(iseed)" should set i = 0 for all values of iseed. RAN is a general random number generator of the multiplicative congruential type. The result is a floating-point number that is uniformly distributed in the range between 0.0 inclusive and 1.0, exclusive.
According to the URL which I gave: RAN stores a value in ISEED and uses it later to calculate the next random number. RAN uses the following algorithm to calculate the value and update the seed: SEED = MOD(69069 * SEED + 1,2 ** 32) SEED is a 32-bit number whose high-order 24 bits are converted to a floating-point number and stored in Y. RAN returns Y and stores the new seed in ISEED. Which is slightly different than what you implemented, rand_seed = GFC_RAND_A * rand_seed % GFC_RAND_M; what you implemented what it says is the defintion: SEED = (69069 * SEED + 1)%(2 ** 32) I think my example was just to show RAN was not implemented as I was trying to compile someone's else code.
I think we can make an alias to my implementation, once Paul and I work out the details. The "+ 1" in "69069 * seed + 1" is need to guard against a pathalogical seed=0. I guard against this problem in srand() by explicitly checking for seed=0. Yes, my implementation will probably generate a different sequence of random numbers in comparison to RAN(), but if someone is using RAN() or RAND() then they don't really care about the randomness in their random numbers. The PRNG in RANDOM_NUMBER is a good PRNG and the PRNG in rand() sucks. Do we really need another, slightly different, sucky PRNG in gfortran.
Created attachment 6767 [details] Add alias for RAN() to RAND() This patch adds an alias for HP FORTRAN 77/iX RAN() function to the g77 compatible RAND() function. RAND() is implemented with a slightly different multiplicative congruent PRNG. IMHO, the difference is immaterial because if someone is using RAND() or RAN(), they really aren't interested in good quality PRN.
Steve that seems like a good patch, maybe adding a way to turn on/off the intrinsic would be nice (aka with pedantic for now or something like that).
Andrew, I don't know how to enclose RAN() in an option. Reading through intrinsic.c, gfortran builds tables of intrinsic function and subroutine names. Currently, we can't mark a member of a table for inclusion/exclusion by an option. Although I agree with you on the use of an option, I think this would require a massive rewrite of intrinsic.c. Frankly, I lack the skill to do such a rewrite before 3.5 is released.
(In reply to comment #11) > Andrew, I don't know how to enclose RAN() in an option. Reading through > intrinsic.c, gfortran builds tables of intrinsic function and subroutine > names. Currently, we can't mark a member of a table for inclusion/exclusion > by an option. Although I agree with you on the use of an option, I think > this would require a massive rewrite of intrinsic.c. Frankly, I lack the > skill to do such a rewrite before 3.5 is released. What we could do is add an option, say -fno-nonstandard-intrinsics, and then conditionalize the add_sym calls for all nonstandard intrinsics on this flag not being set, i.e. if (!gfc_option.only_standard) { add_sym ("fancyintrinsic"); add_sym ("fancyintrinsic2"); } add_sym ("standardintrinsic"); etc.
Subject: Re: RAN (extension) intrinsic/function not supported On Tue, Aug 31, 2004 at 07:21:51PM -0000, tobi at gcc dot gnu dot org wrote: > > ------- Additional Comments From tobi at gcc dot gnu dot org 2004-08-31 19:21 ------- > (In reply to comment #11) > > Andrew, I don't know how to enclose RAN() in an option. Reading through > > intrinsic.c, gfortran builds tables of intrinsic function and subroutine > > names. Currently, we can't mark a member of a table for inclusion/exclusion > > by an option. Although I agree with you on the use of an option, I think > > this would require a massive rewrite of intrinsic.c. Frankly, I lack the > > skill to do such a rewrite before 3.5 is released. > > What we could do is add an option, say -fno-nonstandard-intrinsics, and > then conditionalize the add_sym calls for all nonstandard intrinsics on > this flag not being set, i.e. > if (!gfc_option.only_standard) > { > add_sym ("fancyintrinsic"); > add_sym ("fancyintrinsic2"); > } > add_sym ("standardintrinsic"); > etc. > Where are you doing this? AFAIK, the list of intrinsics is constructed when gfortran is compiled not when you execute gfortran. At runtime we need to be able to regenerate the expected list of intrinsics from the master. To me, this means we need to tag each specific and generic intrinsic procedure with a standard.
The standard dependence thing has been solved by Janne in PR 17590 and the attached patch. It is still waiting for review, though. Once this is in, it should be possible to submit this patch.
This bug report can be closed. Both the alias for RAN and Janne's handling of specifying the requisite standard have been in the gfortran tree for quite sometime. -- steve
Fixed.