odd compiler complaints with large numbers

I don't know what to think of the data I see with silverfrost. The largest
integer that executes with this little program is 2.1 billion, which is a
few orders of magnitude short of the 13 that it promises to deliver:


implicit none
integer, parameter :: i13 = selected_int_kind(13)
integer(i13), parameter:: trials = 2100000000
integer(i13):: i
integer:: counter


real:: harvest, ratio
CALL init_random_seed

counter = 0
do i = 1, trials
call random_number(harvest)
if (harvest ==0.50) then
print *, i, harvest
counter = counter + 1
end if
end do
ratio= real(trials)/real(counter)
print *, "frequency was ", ratio

contains
SUBROUTINE init_random_seed()
INTEGER :: i, n, clock
INTEGER, DIMENSION(, ALLOCATABLE :: seed

CALL RANDOM_SEED(size = n)
print *, "n=", n
ALLOCATE(seed(n))

CALL SYSTEM_CLOCK(COUNT=clock)
print *, "clock=", clock

seed = clock + 37 * (/ (i - 1, i = 1, n) /)
CALL RANDOM_SEED(PUT = seed)
print *, "seed= ", seed

DEALLOCATE(seed)
END SUBROUTINE
end program

Typical output is:
2063773121 0.500000
2070779538 0.500000
2090015224 0.500000
2093563823 0.500000
frequency was 1.590909E+07

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.

If I add the _i13 tag to this constant, the compiler error is:
error 637 - Internal compiler error - floating point exception

I'd be curious how others' mileage fares with large integers.

--
We must respect the other fellow's religion, but only in the sense and to
the extent that we respect his theory that his wife is beautiful and his
children smart. 5
H. L. Mencken

Ron Ford <ron@example.invalid> 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).

> 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.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

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

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

Ron,

Runs fine on version 5.10.0 (Win32).

Which version are you using?

Regards,
Mark

On Thu, 28 Aug 2008 23:54:43 -0600, Ron Ford <ron@example.invalid>
wrote:

>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.
>
>If I add the _i13 tag to this constant, the compiler error is:
>error 637 - Internal compiler error - floating point exception
>
>I'd be curious how others' mileage fares with large integers.
--
|\ _,,,---,,_ A picture used to be worth a
ZZZzzz /,`.-'`' -. ;-;;, thousand words - then along
|,4- ) )-,_. ,\ ( `'-' came television!
'---''(_/--' `-'\_)

Mark Stevens (mark at thepcsite fullstop co fullstop uk)

This message is provided "as is".

On Sat, 30 Aug 2008 06:53:53 +0100, Mark Stevens posted:

> Ron,
>
> Runs fine on version 5.10.0 (Win32).
>
> Which version are you using?
>
> Regards,
> Mark
Mark,

I've got the same silverfrost that I've had for a while. I've gone to the
silverfrost website to find what I hear is now Plato IV, but been unable to
find it.

What I *really* want is a silverfrost that has the iso_c_binding module.
--
What men value in this world is not rights but privileges. 7
H. L. Mencken

On Fri, 29 Aug 2008 17:08:10 -0600, Ron Ford <ron@example.invalid>
wrote in <t8ctyu6zubc1$.dlg@example.invalid>:

> 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.

That depends on your random number generator. I know of some
widely-used PRNGs that return only 2^32-1 numbers, so you can easily
generate a floating-point bit-pattern that won't match a return value.
(Many PRNGs, including the ones mentioned above, won't return 0.0 - none
should return 1.0, IMHO.) If you're looking at double precision, the
possibility of these returning a given bit-pattern in [0.5,1) is 1 in
2^21[1], in [.25,0.5) it's 1 in 2^22, etc.

[1] I may be off by 1 or 2 in the exponent; I'm not taking the time to
fully work it out.

--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

Ron Ford wrote:
> On Sat, 30 Aug 2008 06:53:53 +0100, Mark Stevens posted:
> > Runs fine on version 5.10.0 (Win32).
> >
> > Which version are you using?
>
> I've got the same silverfrost that I've had for a while. I've gone to the
> silverfrost website to find what I hear is now Plato IV, but been unable to
> find it.

I just d/l'ed (from a outside site linked to by Silverfrost) ver
5.21.0

C:\Users\epc\temp>ftn95 zz.f95
[FTN95/Win32 Ver. 5.21.0 Copyright (c) Silverfrost Ltd 1993-2008]
NO ERRORS [<INIT_RANDOM_SEED> FTN95/Win32 v5.21.0]
0013) if (harvest ==0.50) then
WARNING - Comparing floating point quantities for equality may give
misleading
results
NO ERRORS, 1 WARNING [<main program> FTN95/Win32 v5.21.0]

Note the warning.

In theory, the probability of obtaining any one floating point value
is ZERO. But of course floating point is really an approximation with
limited precision, etc., etc., etc.

The last time I looked at the internals of vendor supplied random
number routines, it was common to produce a bit pattern, then -
regarding that as an integer - divide by a power of 2 to "float" the
result. Sometimes this was done by masking in the bits for sign and
exponent. IIRC IBM hex floating point was this way.

For example, Apple Pascal generated 15 bits, and divided by 2**15. MS-
Basic/BasicA generated 24 bits and divided by 2**24.

For your program, the output [on my system with FTN95] was

n= 1
clock= 588438982
seed= 588438982
6426078 0.500000
31050566 0.500000
34647758 0.500000
34666682 0.500000
39301813 0.500000
[snip]
2008560744 0.500000
2011942733 0.500000
2021783196 0.500000
2022411699 0.500000
2022921567 0.500000
frequency was 1.693548E+07

Execution time was approx 2 minutes (2:03) excluding the 5 seconds
during which the nag/splash screen appeared.

- e

e p chandler wrote:

> The last time I looked at the internals of vendor supplied random
> number routines, it was common to produce a bit pattern, then -
> regarding that as an integer - divide by a power of 2 to "float" the
> result. Sometimes this was done by masking in the bits for sign and
> exponent. IIRC IBM hex floating point was this way.

For any format without a hidden one, it is about that easy.

Though my favorite trick for IBM S/360 random number generators
was allowing for either INTEGER or REAL. If you declared it
INTEGER, you got an integer between 0 and 2**31-1, if REAL
between 0.0 and (less than) 1.0!

INTEGER functions return the result in general register 0,
REAL functions in floating point register zero. The
random number generators did both.

-- glen

"Ron Ford" <ron@example.invalid> wrote in message news:bfvu8p4xy824$.dlg@example.invalid...
>
> I don't know what to think of the data I see with silverfrost. The largest
> integer that executes with this little program is 2.1 billion, which is a
> few orders of magnitude short of the 13 that it promises to deliver:

> 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.

that's corrrect, but read the error message.
The constant (that's CONSTANT) has s.i.k 3,
which is the default for integers.

"Ron Ford" <ron@example.invalid> wrote in message news:t8ctyu6zubc1$.dlg@example.invalid...
> On Thu, 28 Aug 2008 23:02:53 -0700, Richard Maine posted:
>
> > Ron Ford <ron@example.invalid> 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.

No, the compiler can't do that because the integer 2,200,000,000 is already
too large for a default integer! Thus, it can't store it as a default
integer and ipso facto can't convert it.