Re: odd compiler complaints with large numbers

On Thu, 28 Aug 2008 23:02:53 -0700, Richard Maine posted:

Ron Ford <ron@xxxxxxxxxxxxxxx> 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
.