在Fortran过程中将大小作为参数VS传递为形状

本文介绍了在Fortran过程中将大小作为参数VS传递为形状的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在尝试确定这两个选项中的哪一个最好：

子例程sqtrace（Msize，Matrix ，Value）整数，intent（in）:: Msize 实数* 8，intent（in）:: Matrix（Msize，Msize） real * 8，intent（out）::价值 [指令...] 结束子程序sqtrace

VS

子例程sqtrace（Matrix，Value） real * 8，intent（in）： ：Matrix（:, :) real * 8，intent（out）::值 if（size（Matrix，1）/ = size（Matrix，2））然后 [错误情况说明] 如果 [说明...] 结尾子程序sqtrace

我了解您在编译警告时，第一种情况应在编译时自动检查是否调用了 sqtrace 符合指示的尺寸。但是，我不知道例如当给定参数可分配时，编译器是否可以执行这些检查（如果这种分配取决于运行时确定的其他情况，则更是如此）。第二个需要一个显式的接口并具有更多的代码（检查），但似乎会捕获更多的错误。

分别使用in和in的优点/缺点是

解决方案

首先，一些术语。考虑声明为

real :: a（n）的伪参数！一个显式形状数组 real :: b（:)！假定的形状数组实际可分配:: c（:)！延迟形状数组 real :: d（*）！假定大小数组

（延迟形状数组也可以是指针而不是可分配的）。 / p>

在给定的情况下，我不会回答哪个更好，但是会向程序员详细说明一些重要的特征，如果有的话，留给程序员。残酷的是，许多人将显式形状数组视为 Fortran 77，而将形状数组视为 Fortran 90 +。

Shape ：

• 显式形状数组的形状遵循其声明；
• 假定形状形状数组虚拟参数是实际参数的形状；
• 延迟形状虚拟参数的形状可能是未定义的，在过程中可能已定义，或者是实际参数的形状。

连续性：

• 显式形状数组很简单连续的；
• 一个假定的形状数组虚拟参数的连续性与关联的实际参数的连续性有关；
• 一个延迟的形状虚拟参数可能是实际参数，或取决于过程的执行情况。

对实际参数的限制：

• 与显式形状数组关联的实际参数必须具有至少与虚拟参数一样多的元素；
• 与假定形状数组关联的实际参数本身不得具有大小；
• 实际与假定或延迟的形状数组关联的参数必须与虚拟参数具有相同的等级。

调用范围中的接口：

• 如果伪参数具有假定或延迟的形状，则引用范围必须可访问该过程的显式接口。

考虑 real a（6）。这可能是假人的实际论点

真实b（3）真实c（2,3）实d（:)！使用显式接口

a（1 :: 2）可能与 b 相关联，但由于 b 涉及连续的复制/复制， 。与 d 关联时不需要复制/复制，但是可以。

还有很多其他方面，但是希望这是最初的高级介绍。

I'm trying to decide which one of these two options would be the best:

subroutine sqtrace( Msize, Matrix, Value ) integer, intent(in) :: Msize real*8, intent(in) :: Matrix(Msize, Msize) real*8, intent(out) :: Value [instructions...] end subroutine sqtrace

VS

subroutine sqtrace( Matrix, Value ) real*8, intent(in) :: Matrix(:,:) real*8, intent(out) :: Value if ( size(Matrix,1) /= size(Matrix,2) ) then [error case instructions] end if [instructions...] end subroutine sqtrace

I understand that when you compile with warnings, the first case should automatically check at compile time if calls to sqtrace comply with the size indicated. However, I don't know if the compiler can perform those checks when the given arguments are allocatable, for example (more so if such allocation depends on other things that are determined at runtime). The second one requires an explicit interface and has more code (the checks), but would seem to catch more errors.

Which are the advantages/disadvantages of using each and in which cases should one go with one over the other?

解决方案

First, some terminology. Consider the dummy arguments declared as

real :: a(n) ! An explicit shape array real :: b(:) ! An assumed shape array real, allocatable :: c(:) ! A deferred shape array real :: d(*) ! An assumed size array

(a deferred shape array may also be a pointer rather than an allocatable).

I won't answer in terms of which is better in a given situation, but will simply detail some of the important characeristics leaving choice, where there is one, to the programmer. Crudely, many view explicit shape arrays as "Fortran 77" and assumed shape arrays as "Fortran 90+".

Shape:

• the shape of an explicit shape array follows its declaration;
• the shape of an assumed shape array dummy argument is that of the actual argument;
• the shape of a deferred shape dummy argument may be undefined, becoming defined in the procedure, or that of the actual argument.

Contiguousness:

• an explicit shape array is simply contiguous;
• an assumed shape array dummy argument's contiguousness relates to that of the associated actual argument;
• a deferred shape dummy argument may be that of the actual argument, or depending on the procedure's execution.

Restrictions on actual argument:

• an actual argument associated with an explicit shape array must have at least as many elements as the dummy argument;
• an actual argument associated with an assumed shape array must not itself be assumed size;
• an actual argument associated with an assumed or deferred shape array must be of the same rank as the dummy argument.

Interfaces in the calling scope:

• if a dummy argument is of assumed or deferred shape, the referencing scope must have accessible an explicit interface for the procedure.

Consider real a(6). This may be an actual argument to the dummies

real b(3) real c(2,3) real d(:) ! With an explicit interface available

a(1::2) may be associated with b but as b is contiguous copy-in/copy-out will be involved. Copy-in/copy-out needn't be involved when associated with d, but it may be.

There are plenty of other aspects, but hopefully this is an initial high-level introduction.