- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

When I compile the following snippet:

program dimension_specifications_incompatible implicit none integer,dimension(1:3,1:3)::a call print_matrix(a) end program dimension_specifications_incompatible subroutine print_matrix(b) implicit none integer,dimension(1:3,1: )::b print *,b end subroutine print_matrix!b

I get the following compiler error:

error #6644: The dimension specifications are incompatible.integer,dimension(1:3,1: )::b ----------------------------------------^

Aren't partially assumed-shape arrays allowed in fortran? since fully defined shapes,and fully assumed ones are allowed, and checked, I cannot understand the problem with a partially assumed one.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

l;ace print_matrix into a module and use it such that its interface is known. Assumed shape called procedures require interfaces.

Jim Dempsey

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

In my original code, said functions are placed in a module yes. I only included a main for completeness of the sample program here, but the problem is in the subroutine alone, whether as part of a module or not. So for array dummy arguments, I can declared them partially or fully assume-shape, but not in all ways:

subroutine test_method(a,b,c,d,e) integer,dimension( : , : )::a ! legal integer,dimension(0: ,0: )::b ! legal integer,dimension(0:3,0:5)::c ! legal integer,dimension(0:3, : )::d ! illegal integer,dimension(0:3,0: )::e ! illegal end subroutine test_method

The last two I'm worried about. Thanks again for your time.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

See 5.1.2.5.2, R514 of the Fortran 2008 standard. You may specify each dimension as ":" or "d1:", but not as "d1:d2". If d1 is not specified, the lower bound is taken to be 1.

Explanation: if you specify d1 and d2, there is nothing left to "assume"!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

try using assumed size syntax:

integer,dimension(0:3,0:* )::e

Jim Dempsey

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Trent Hawkins wrote:

.. Aren't partially assumed-shape arrays allowed in fortran? since fully defined shapes,and fully assumed ones are allowed, and checked, I cannot understand the problem with a partially assumed one.

IMO what you are asking about seems without a justifiable use case. Assumed-shape dummy arguments, which then require explicit interfaces, will have all the shape information on **each** of the dimensions from the actual argument, so why would there be a need for a partial capability?

If what you are looking for is only to reindex the lower bound of a dimension but not explicitly state the shape along a dimension, you can do so with "li:" syntax as in "arr(:,l2:,:)" where the lower bound along rank 2 starts at l2 where the first and third dimensions start at unity.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

>>so why would there be a need for a partial capability?

Because the partial (as in the two illegals in #3) provide for the shape, bounds and size of the lead-in indices, thus providing this information for the compiler to optimize indexing of the array.

Jim Dempsey

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

jimdempseyatthecove wrote:

>>so why would there be a need for a partial capability?

Because the partial (as in the two illegals in #3) provide for the shape, bounds and size of the lead-in indices, thus providing this information for the compiler to optimize indexing of the array.

Jim Dempsey

Jim,

I hope someone from Intel will chime in, but I see little evidence the Intel compiler will be able to do any further optimization with respect to any code constructs with such partial information relative to the standard-conforming assumed-shape arrays. You will know starting with 2008 revision, Fortran standard offers CONTIGUOUS attribute and introduces the concept of 'simply contiguous' to further aid optimization but I'm not quite convinced the benefits of these standard features are on offer yet to the coders:

https://software.intel.com/en-us/fortran-compiler-18.0-developer-guide-and-reference-contiguous

These features seem to make more sense than partial shape aspects.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

FortranFan,

The point is not with respect to the contiguity, rather it is whether or not if the compiler can generate indexing code that need not inspect the array descriptor in order to figure out the indexed entry into the array. Granted, in a loop of any significance, this may not mean much savings, but in small iterative loops, this can be significant.

Jim Dempsey

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page