您看到的错误是由于在Fortran 90之前频繁出现的旧声明样式,但从未成为标准。因此,编译器不接受(形式上不正确的)代码。
在Fortran 90之前的旧时代,你只有两种类型的实数: REAL 和 DOUBLE PRECISION 。这些类型取决于平台,但大多数编译器 如今 将它们映射到 IEEE754格式 binary32和binary64。
REAL
DOUBLE PRECISION
但是,有些机器提供不同的格式,通常具有额外的精度。为了使它们可以访问Fortran代码,类型 REAL*n 被发明了 n 来自一组依赖于编译器的值的整数文字。这种语法从来都不是标准的,因此如果不阅读其文档,您无法确定它对给定编译器意味着什么。
REAL*n
n
在现实世界中,大多数编译器没有被要求严格遵守标准(有一些选项,如 -std=f95 )至少会认出来 REAL*4 和 REAL*8 ,将它们映射到前面提到的binary32 / 64格式,但其他一切都完全取决于平台。你的编译器 的 可以 强> 有一个 REAL*10 x86 387 FPU使用的80位算法的类型,或a REAL*16 键入一些128位浮点数学。但是,重要的是要强调,由于语法不是标准的,因此该类型的含义可能会从编译器变为编译器。
-std=f95
REAL*4
REAL*8
REAL*10
REAL*16
最后,在Fortran 90中提到一种不同的方式 种 真实和整数类型的标准。新的语法是 REAL(n) 要么 REAL(kind=n) 并得到所有符合标准的编译器的支持。但是,价值观 ñ 仍然依赖于编译器,但该标准提供了三种获取特定可重复结果的方法:
REAL(n)
REAL(kind=n)
该 SELECTED_REAL_KIND function,它允许您在系统中查询n的值,以指定是否需要具有特定精度和范围要求的实数类型。通常,你所做的就是要求它一次并将结果存储在一个 INTEGER, PARAMETER 在声明有问题的实变量时使用的变量。例如,您将声明一个至少包含15位精度(十进制)和指数范围至少为100的类型,如下所示:
SELECTED_REAL_KIND
INTEGER, PARAMETER
INTEGER, PARAMETER :: rk = SELECTED_REAL_KIND(15, 100) REAL(rk) :: v
ISO_C_BINDING
C_FLOAT
C_DOUBLE
C_LONG_DOUBLE
double
REAL(C_DOUBLE) :: d
ISO_FORTRAN_ENV
REAL32
REAL64
REAL128
REAL(real128) :: q
如果您使用的是GNU gfortran,请尝试“real(kind = 10)”,这将为您提供10个字节(80位)的扩展精度。我正在转换一些较旧的F77代码来运行浮点数学测试 - 它具有四精度(你提到的真正的* 16)定义但未使用,因为正确指出的其他答案指出(扩展精度格式往往是机器/编译器具体)。我使用的gfortran 5.2不支持真实(kind = 16),令人惊讶。但gfortran(可用于64位MacOS和64位Linux机器)确实具有“真实(种类= 10)”,它将为您提供超出典型真实* 8或“双精度”的精度,因为它在某些Fortran编译器。 如果您的旧Fortran代码正在调用C程序和/或可能假设如何处理精度并表示浮点数,请小心。您可能必须深入了解正在发生的事情,并仔细检查代码,以确保事情按预期工作,特别是如果fortran和C例程正在相互调用。这是关于四精度的GNU gfortran信息的URL: https://people.sc.fsu.edu/~jburkardt/f77_src/gfortran_quadmath/gfortran_quadmath.html 希望这可以帮助。
当我们猜测而不是请求正确的代码和完整的细节时,我会冒昧地说其他两个答案是不正确的。
错误消息
Error: Old-style type declaration REAL*16 not supported at (1)
的 才不是 强> 表示不支持REAL * n语法。
错误消息具有误导性。它实际上意味着不支持16字节实数。如果OP通过类型符号(在返回gfortran类型16的许多方式中的任何一种)中请求相同的真实,则错误消息将是:
Error: Kind 16 not supported for type REAL at (1)
这可能发生在一些gfortran版本中。特别是在MS Windows中。
只需非常快速的谷歌搜索错误消息即可找到此解释: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56850#c1
它并没有抱怨旧的语法是问题,它只是提到它,因为提及种类可能会更加混乱(特别是对于类型16的COMPLEX * 32)。
主要信息是: 的 我们真的应该关闭这些问题 强> 并等待适当的细节,而不是猜测和upvoting问题,OP甚至无法复制编译器吐出的完整消息。