I've noted that if I use integer(16)
variables, when I use print
, the output contains the exact number of spaces expected. Thus, when I use (some might recognize a project euler problem here)
implicit none
integer(16)::sum_sq,sq_sum,diff,i
sum_sq=0;sq_sum=0;
do i=1,100
sum_sq=sum_sq+i*i
sq_sum=sq_sum+i
enddo
diff=abs(sq_sum**2-sum_sq)
print *, "The difference is", diff
I get
The difference is 25164150
as the output, but when I use integer(8)
or integer
for the variables, I get
The difference is 25164150
as the output. This occurs with and without the -m64
flag and only on gfortran (my ifort does not seem to accept kind=16
, a separate issue to be dealt with, but returns the output with the spaces for integer(8)
).
Does anyone know why this occurs?
As already answered, you are using list-directed IO, which while convenient, is not completely specified by the language standard. So you will find idiosyncrasies. If you want to control the output will need to use a format. Also convient is the format specifier "I0", which uses the minimum number of digits required to output the item.
As a side issue, "integer (N)" is not guaranteed to be an N-byte integer. It is not the same as "integer*N", which is not part of the language standard. Many compilers use for the kind values the number of bytes of the type, but there are exceptions. In hindsight, it was a mistake to use integer values to designate integer, real & logical sub-types. If you want to select types by the number of bytes, there are methods starting with Fortran 2003. The ISO_C_Binding module of Fortran 2003 provides type designators such as C_INT32_T, C_INT64_T and C_INT128_T. The ISO_FORTRAN_ENV module for Fortran 2008 provides INT8, INT16, INT32 and INT64.
This happens because you are using default formatting for the output.
print*
is equivalent to write(unit=*,fmt=*)
, where fmt=*
means use default formatting for the output, which may be compiler dependent. Default formatting uses as much space is possibly needed by the data type being output, without making adjustments based on the value.
Consider following code:
integer(kind=4) :: a ! short integer for my compiler
integer(kind=8) :: b ! long integer for my compiler
a = 23
b = huge(a)
print*,a ! small value, short integer, we expect spaces
print*,huge(a) ! maximum value, short integer, we expect no spaces
print*,huge(b) ! maximum value, long integer, we expect no spaces
print*,b ! medium lenght value, long integer, we expect spaces
end
When compiler with gfortran, the output is:
23
2147483647
9223372036854775807
2147483647
The first line is a small number in 4-byte integer representation. Notice the spaces to fill up to the maximum possible size. Second line is the largest value a 4-byte integer can take. Fits tightly in output, no spaces. Third line is the largest value of an 8-byte integer. Fits tightly. The fourth line is the same value from the 2nd line, but in 8-byte integer representation. Notice the spaces.
This answers why you get spaces in output for default formatting. It does not quite answer your question exactly, which is why there are no spaces in output for a quad-precision integer. I don't know. Neither of my compilers (pgf90 10.6-0
, ifort 12.0.2.137
, gfortran 4.5.1
) support quad-precision integer. Could be a compiler hackery. Someone might have more experience with this part, and hopefully they will chime in.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With