Fortran - what is the fortran 95 way for integer*8

Author

what is the fortran 95 way for integer*8

Kamaraju Kusumanchi

2004-06-25, 7:43 pm

This is in continuation of fftw and fortran thread. Sorry for opening up
another thread.

I would like to know what is the proper way to declare fftw plan
variables. The manual suggests integer*8. But if I compile a program
with this statement, ifc compiler gives a warning

$ifc fftwtest.f90 -lfftw3 -lm
program FFTWTEST

integer*8 :: plan
^
Warning 2 at (7:fftwtest.f90) : Type size specifiers are an extension to
standard Fortran 95

82 Lines Compiled

So I am wondering if there is a better way out there. I tried reading
Fortran 95 handbook, complete iso/ansi reference but could not get any
useful information. Any suggestions are highly appreciated.

*********** sample code ***********

program fftwtest
include 'fftw3.f'
!integer, parameter :: i4b = selected_int_kind(9) !232 = 4,294,967,296
integer, parameter :: dpc = kind((1.0D0,1.0D0))
complex(dpc) :: input(1024), output(1024)
!integer(i4b) :: plan
integer*8 :: plan

call dfftw_plan_dft_1d(plan,1024,input,output
, FFTW_FORWARD,FFTW_MEASURE)
do i=1,1024
input(i) = cmplx(log(i*10.0), log(i+2.0))
end do
call dfftw_print_plan(plan)
call dfftw_execute(plan)
write(*,*) output
call dfftw_destroy_plan(plan)
end

Paul Van Delst

2004-06-25, 7:43 pm

Kamaraju Kusumanchi wrote:
> This is in continuation of fftw and fortran thread. Sorry for opening up
> another thread.
>
> I would like to know what is the proper way to declare fftw plan
> variables. The manual suggests integer*8. But if I compile a program
> with this statement, ifc compiler gives a warning
>
> $ifc fftwtest.f90 -lfftw3 -lm
> program FFTWTEST
>
> integer*8 :: plan
> ^
> Warning 2 at (7:fftwtest.f90) : Type size specifiers are an extension to
> standard Fortran 95
>
> 82 Lines Compiled
>
> So I am wondering if there is a better way out there. I tried reading
> Fortran 95 handbook, complete iso/ansi reference but could not get any
> useful information. Any suggestions are highly appreciated.

This is how I do it. In my "type_kinds.f90" module I have the following definitions,

INTEGER, PARAMETER, PUBLIC :: Long = SELECTED_INT_KIND(8) ! Long integer
INTEGER, PARAMETER, PRIVATE :: LLong_t = SELECTED_INT_KIND(16) ! LLong integer
INTEGER, PARAMETER, PUBLIC :: LLong = (((1 + SIGN(1, LLong_t)) / 2) * LLong_t) + &
(((1 - SIGN(1, LLong_t)) / 2) * Long )

and then to decalre an integer*8 equivalent,

USE type_kinds
INTEGER( LLong ) :: plan

Note the use of the LLong_t and LLong. This is something James van Buskirk posted a number
of years ago to handle the case where a particular compiler doesn't support an integer
with kind SELECTED_INT_KIND(16). If the compiler doesn't, then the PUBLIC LLong defaults
to the regular Long kind (equivalent to 4-byte int).

cheers,

paulv

Kamaraju Kusumanchi

2004-06-25, 7:43 pm

Paul Van Delst wrote:
> This is how I do it. In my "type_kinds.f90" module I have the following
> definitions,
>
> INTEGER, PARAMETER, PUBLIC :: Long = SELECTED_INT_KIND(8) !
> Long integer
> INTEGER, PARAMETER, PRIVATE :: LLong_t = SELECTED_INT_KIND(16) !
> LLong integer
> INTEGER, PARAMETER, PUBLIC :: LLong = (((1 + SIGN(1, LLong_t)) / 2)
> * LLong_t) + &
> (((1 - SIGN(1, LLong_t)) / 2)
> * Long )

I like this clever idea. Just a little confirmation. Should not it be
SELECTED_INT_KIND(9) and SELECTED_INT_KIND(19) instead of 8 and 16?

Since 4 byte integer = 2^(8*4) = 2^32 = 4,294,967,296 = 4.3e9 and
8 byte integer = 2^(8*8) = 2^64 = 18,446,744,073,709,551,616 = 1.8e19

please correct me if I am wrong.

raju

James Giles

2004-06-25, 7:43 pm

Kamaraju Kusumanchi wrote:
....
> [...] Should not it be
> SELECTED_INT_KIND(9) and SELECTED_INT_KIND(19) instead of 8 and 16?
>
> Since 4 byte integer = 2^(8*4) = 2^32 = 4,294,967,296 = 4.3e9 and
> 8 byte integer = 2^(8*8) = 2^64 = 18,446,744,073,709,551,616 = 1.8e19

Probably the second should be SELECTED_INT_KIND(18).
The sign bit takes some space. So, the range of values of an
8 byte kind would be -2^63 through 2^63-1. The latter value
is roughly 9.2e18.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Richard Maine

2004-06-25, 7:43 pm

Kamaraju Kusumanchi <kk288@cornell.edu> writes:

> I like this clever idea. Just a little confirmation. Should not it be
> SELECTED_INT_KIND(9) and SELECTED_INT_KIND(19) instead of 8 and 16?

> please correct me if I am wrong.

Either will work. There is no single "right" answer. See my longish
posting from earlier today in the "Specifying at 16-bit integer"
thread for comments about selected_*_kind not being a very good
way of describing what people most often want.

To directly answer your current question, note that selected_int_kind
gets you a kind that has *AT LEAST* the precision you ask for. It doesn't
have to be exact (which it couldn't be since binary forms don't correspond
exactly to integer numbers of decimal digits), or even close.

If you had to specify exactly the right number, then the intrinsics
would be really useless instead of just long-winded and a bit cryptic
as they are now. (They are cryptic enough to need calculations like
yours and explanations like this). You'd have to know the right
numbers for each system you wanted to port to. If you have to know
the right numbers for each system anyway, you might as well just look
up the right KIND numbers in the first place and leave out the extra
step of the intrinsic. (Yes, there are systems that, for various
reasons, give different precisions for the same "size" reals - not so
much an issue for integers, it is true).

Assuming a system that has integers with sizes of 2, 4, and 8 bytes
(and possibly others larger or smaller, but nothing else in between),
you will get the 4-byte integer for anything from selected_int_kind(5)
to selected_int_kind(9). You will get the 8-byte integer for anything
from selected_int_kind(10) to selected_int_kind(19).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard Maine

2004-06-25, 7:43 pm

Richard Maine <nospam@see.signature> writes:

> Assuming a system that has integers with sizes of 2, 4, and 8 bytes
> (and possibly others larger or smaller, but nothing else in between),
> you will get the 4-byte integer for anything from selected_int_kind(5)
> to selected_int_kind(9). You will get the 8-byte integer for anything
> from selected_int_kind(10) to selected_int_kind(19).
---------------------------------------^^----------

Oops. As Giles pointed out (and I read right after posting), that
should be 18. My explanation still holds, but my number was off.

I clearly associate with too many mathematicians...you know, those
people who specialize in abstract mathematics but can't do
arithmetic. It rubs off. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Paul Van Delst

2004-06-25, 7:43 pm

Kamaraju Kusumanchi wrote:
> Paul Van Delst wrote:
>
>
>
> I like this clever idea. Just a little confirmation. Should not it be
> SELECTED_INT_KIND(9) and SELECTED_INT_KIND(19) instead of 8 and 16?
>
> Since 4 byte integer = 2^(8*4) = 2^32 = 4,294,967,296 = 4.3e9 and
> 8 byte integer = 2^(8*8) = 2^64 = 18,446,744,073,709,551,616 = 1.8e19
>
> please correct me if I am wrong.

Don't forget negative numbers too. 4-byte ~= -2^31 to +2^31 = +/-2.14e09

But regardless:

From Fortran 90/95 Explained, 2nd ed pg 178:

selected_int_kind(r) returns the default integerscalar that is the kind type parameter
value for and integer data type able to represent all integer values in the range
-10**r < n < 10**r. .....

So my selected_int_kind(8) has to handle numbers -10^8 to 10^8. If the "resolution" of
integer kind types was finer than it generally is, yes it would be a problem. But, most
compilers still only have the usual 1-, 2-, 4-, and 8-byte integer types (not 3- or 6-byte
types for e.g.). Now, a 2-byte integer can't handle a number like 10^8 so the compiler
says, fine, I'll give him a 4-byte integer. Same for 10^16 -- it's two orders of magnitude
less than 2^63, but a 4-byte integer can't hold that value, so I obviously need an 8-byte one.

cheers,

paulv

p.s. Be forewarned that if you use the pgf90 compiler, PGI have *STILL* not fixed the bug
that causes the parameter definition

INTEGER, PARAMETER, PUBLIC :: LLong = (((1 + SIGN(1, LLong_t)) / 2) * LLong_t) + &
(((1 - SIGN(1, LLong_t)) / 2) * Long )
from producing a compiler error:

PGF90-S-0087-Non-constant expression where constant expression required (blah.f90: 5)

which is incorrect (AFAICT) as the above is a valid initialisation expression since SIGN()
is an elemental intrinsic function that has arguments and results of type integer.

jbs@watson.ibm.com

2004-06-25, 7:43 pm

In article <casim6$7pa$1@news01.cit.cornell.edu>,
on Thu, 17 Jun 2004 13:00:17 -0400,
Kamaraju Kusumanchi <kk288@cornell.edu> writes:
>This is in continuation of fftw and fortran thread. Sorry for opening up
>another thread.
>
>I would like to know what is the proper way to declare fftw plan
>variables. The manual suggests integer*8. But if I compile a program
>with this statement, ifc compiler gives a warning
>
>$ifc fftwtest.f90 -lfftw3 -lm
> program FFTWTEST
>
> integer*8 :: plan
> ^
>Warning 2 at (7:fftwtest.f90) : Type size specifiers are an extension to
>standard Fortran 95
>
>82 Lines Compiled
>
>So I am wondering if there is a better way out there. I tried reading
>Fortran 95 handbook, complete iso/ansi reference but could not get any
>useful information. Any suggestions are highly appreciated.

I would leave it as integer*8 myself.
James B. Shearer

Sponsored Links