- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi folks,
I wrote some really beautiful function to compare arrays of arbitrary rank using Intel ifort 19.3. The code below compiles and runs perfectly: it gives right results for whatever integer arrays I throw into the function. However I could not find any reference that it is (current or any future) Fortran standard conforming.
PURE LOGICAL FUNCTION array_is_equal(arr1,arr2) RESULT(is_equal)
INTEGER, DIMENSION(..), INTENT(in) :: arr1
INTEGER, DIMENSION(..), INTENT(in) :: arr2
is_equal = .FALSE.
IF (rank(arr1)==rank(arr2)) THEN
IF (all(shape(arr1)==shape(arr2))) THEN
is_equal = all(is_equal_val(arr1,arr2))
END IF
END IF
CONTAINS
ELEMENTAL LOGICAL FUNCTION is_equal_val(v1,v2)
INTEGER, INTENT(in) :: v1 !< First value.
INTEGER, INTENT(in) :: v2 !< Second value.
is_equal_val = v1==v2
END FUNCTION is_equal_val
END FUNCTION array_is_equal
The code uses so-called assumed-rank array so that the function can receive arrays of any rank for comparison. All I could find out is that an intrinsic inquiry function can be used with an assumed-rank array, nothing about a possibility to apply an elemental function element-wise to such an array.
Therefore I wonder if it is a bug or a feature in Ifort 19.3. I really enjoy this code working correctly and hope a lot that it is a feature. It would be really sad if this function would stop working with some future release of Intel Fortran due to some fixed incompatibility with the standard.
I would like to know if the function above conforms with some Fortran standard so that I can confidently use it in production code.
--Aleksey
Link Copied
- « Previous
-
- 1
- 2
- Next »
21 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aleksey,
I think your example in #21 would require the REDUCTION clause.
This said, I do not see how this would implicitly abort evaluation by all threads...
... as well as why it would not permit early abort.
The generated code for early abort as well as not would differ slightly. Note, while EXIT may not be permitted, CYCLE is permitted
result = .true. !$omp parallel do if(.not. result) cycle ! quickly reach end of iteration without further reads if(a1(i) .ne. a2(i)) result = .false. ! do not use result =((a1(i) .eq. a2(i)) end do
The parallel workshare construct could be optimized to perform the equivalent code (vectorized). This is not saying that it currently does, but saying that it could. FWIW, I do not see why EXIT is not permitted for a loop like above. Can someone explain this?
Also, "result =((a1(i) .eq. a2(i))" format would produce unnecessary writes.
Jim Dempsey
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »