问题

Question

问题

将子程序标记为elemental时是否存在任何复杂情况？ This page似乎暗示了这一点，但并没有详细说明它们可能是什么。

注意：我正在标记多个fortran版本，因为我想知道在开发可移植代码时是否应该注意这些版本之间是否存在差异。

实施例

假设我想编写一个元素子程序来转换笛卡尔坐标和极坐标。这可以按如下方式完成：

elemental subroutine calc_xy_from_rt( r, t, x, y )
    real*8, intent(IN)  :: r   ! radius
    real*8, intent(IN)  :: t   ! theta
    real*8, intent(OUT) :: x
    real*8, intent(OUT) :: y
    x = r * cos(t)
    y = r * sin(t)
end subroutine calc_xy_from_rt

因为它是元素的，所以可以在以下上下文中调用它：

program main
    implicit none

    real*8, dimension(1:100) :: r
    real*8, dimension(1:100) :: t
    real*8, dimension(1:100) :: x
    real*8, dimension(1:100) :: y

    ! (Initialize r and t arrays here)

    ! Calculate x and y for each element
    call calc_xy_from_rt( r, t, x, y )   ! gets called 100 times
end program main

我猜这个简单程序不会产生副作用，但我提供了一个例子来使讨论具体并提供一个可以扩展到的MWE说明可能的副作用。

Answer 1

元素子程序的明显复杂性是所有伪参数都必须是标量。有时人们希望元素操作可以访问共享数组：这不能通过参数发生。

此外，如果一个元素子程序是纯粹的，它将受到来自该性质的所有限制。

无论它是否纯净，元素子程序都会受到进一步的限制：

伪参数不能是指针或可分配的;
虚拟参数不能是coarrays;
伪参数必须是数据对象。

至于这些限制如何随着时间和实施而变化，几乎不用担心。

在Fortran 2008之前，所有元素子程序都是纯粹的，并且对coarray伪参数的禁止毫无意义。

此外，编制者必须能够检测到违反这些限制的行为，并且我不知道有任何扩展可以放松它们。

最后，当元素程序出现时，多年前就存在各种编译器错误。除非拿起在叔叔的车库里找到的机器，否则不必过多担心。

Fortran中元素子程序的并发症

问题

实施例

1 个答案: