You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fortran mandates that the default kind of INTEGER occupy one numeric storage unit; so does the default kind of REAL. In 2019, default REAL is expected to be IEEE-754 single precision. Consequently, the default kind of INTEGER ends up having to be 32 bits wide.
This is a problem for real applications using arrays that are (or can be) very large, as the default KIND= parameter values for intrinsic functions like SIZE, SHAPE, LBOUND, UBOUND, FINDLOC, MAXLOC, and MINLOC (*) are all defined to be the default kind of INTEGER. One must determine the proper kind of "long" integer (or assume it) and remember to specify that KIND= on every use of these intrinsic functions in order to ensure that they work with large arrays.
I propose that the default result kinds of these intrinsic functions be redefined to be processor-dependent, so that a processor supporting large memories can do the obvious right thing.
(*) this list is probably incomplete; maybe it should include LEN but that's less of an issue and it would be the hardest to change
The text was updated successfully, but these errors were encountered:
Fortran mandates that the default kind of
INTEGER
occupy one numeric storage unit; so does the default kind ofREAL
. In 2019, defaultREAL
is expected to be IEEE-754 single precision. Consequently, the default kind ofINTEGER
ends up having to be 32 bits wide.This is a problem for real applications using arrays that are (or can be) very large, as the default
KIND=
parameter values for intrinsic functions likeSIZE
,SHAPE
,LBOUND
,UBOUND
,FINDLOC
,MAXLOC
, andMINLOC
(*) are all defined to be the default kind ofINTEGER
. One must determine the proper kind of "long" integer (or assume it) and remember to specify thatKIND=
on every use of these intrinsic functions in order to ensure that they work with large arrays.I propose that the default result kinds of these intrinsic functions be redefined to be processor-dependent, so that a processor supporting large memories can do the obvious right thing.
(*) this list is probably incomplete; maybe it should include
LEN
but that's less of an issue and it would be the hardest to changeThe text was updated successfully, but these errors were encountered: