On Thu, 28 Aug 2008 23:02:53 -0700, Richard Maine posted:
> Ron Ford wrote:
>
>> integer, parameter :: i13 = selected_int_kind(13)
>> integer(i13), parameter:: trials = 2100000000
>
>> If I ask for a trial size of 2.2 billion, I get:
>> error 217 - INTEGER(KIND=3) constant out of range
>>
>> That's crazy, because the s.i.k. for 13 is 4.
>
> which has nothing to do with the literal constant in question. The
> literal constant is a default integer, since you didn't make it
> otherwise. That's a very FAQ - that the kind of a literal constant does
> not depend on context (in this case, the context that you are using it
> in an expression that ends up getting assigned to a parameter of kind
> i13).
So the compiler sucks it in as kind=3, the default, and then promotes it to
s.i.k. 13=4.
>
>> If I add the _i13 tag to this constant,
>
> Yes, that's the correct fix.
>
>> the compiler error is:
>> error 637 - Internal compiler error - floating point exception
>
> Another FAQ. An internal compiler error is a compiler bug, by
> definition. I suggest reporting it to the vendor.
Thanks, Richard, I'm convinced that silverfrost doesn't want my comments or
spare change.
I added the correct tag and cranked up trials to 21 billion with gfortran,
and it executed properly. It takes about ten minutes to execute on my
machine. It makes me wonder how cpu-consuming a random_number call is as
opposed to, say, this block:
if (harvest == 0.3333333333333333333) then
print *, i, harvest
counter = counter + 1
end if
C Unleashed has a table for how expensive certain function calls are in C;
does fortran have something similar?
I can't really decide on a good methodology to determine what the chance is
of hitting a given real in the half-closed unit interval with a
random_number call.
--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken
