|
|
 Up |
|
|
  |
Author: Ron FordRon Ford Date: Aug 28, 2008 22:54
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
|
| Show full article (1.87Kb) |
|
| | 7 Comments |
|
|
Author: nospamnospam Date: Aug 28, 2008 23:02
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).
> 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.
|
| Show full article (1.12Kb) |
|
| | no comments |
|
|
Author: Ron FordRon Ford Date: Aug 29, 2008 16:08
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.
|
| Show full article (1.93Kb) |
| no comments |
|
|
Author: Mark StevensMark Stevens Date: Aug 29, 2008 22:53
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
wrote:
|
| Show full article (0.83Kb) |
| no comments |
|
|
Author: Ron FordRon Ford Date: Aug 30, 2008 02:08
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
|
| |
| no comments |
|
|
Author: Dr Ivan D. ReidDr Ivan D. Reid Date: Aug 30, 2008 03:07
On Fri, 29 Aug 2008 17:08:10 -0600, Ron Ford
wrote in :
> 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".
|
| |
| no comments |
|
|
Author: e p chandlere p chandler Date: Sep 1, 2008 05:08
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 [ 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 [ FTN95/Win32 v5.21.0]
|
| Show full article (2.01Kb) |
| no comments |
|
|
|
|
|
Author: glen herrmannsfeldtglen herrmannsfeldt Date: Sep 2, 2008 04:34
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
|
| |
| no comments |
|
RELATED THREADS |
|
|
|
|
