Dynamically allocate space to be referenced as both real and complex arrays?

Dynamically allocate space to be referenced as both real and complex arrays?

I work with Fourier transforms and PSD calculations. It is very convenient to use an algorithm for the FT calculation that works with a complex array. But to populate this array, and use the FT result to compute the PSD, it is more convenient to address the elements using a Real array. I used to do this using the EQUIVALENCE statement:

INTEGER, PARAMETER :: nhalf = npts / 2
REAL :: a(npts)
COMPLEX :: z(nhalf)

Two problems are developing. First, EQUIVALENCE is becoming obsolete (maybe it already is except for an extension) so I am leary of continuing this practice; second, I would really like to dynamically allocate the storage area (i.e. npts should be read as an input), and I see that dynamically allocated arrays cannot be used in EQUIVALENCE.

As a different but related problem, I used (F77) to be able to obtain effective equivalence by doing the REAL-referenced work in a main program and the COMPLEX-referenced work in a subroutine, thus

CALL fftcalc (a, nhalf, dum1, dum2, ...)
SUBROUTINE fftcalc (z, nhalf, dum1, dum2, ...)
COMPLEX :: z(nhalf)

But this technique no longer works in F90 because corresponding arguments are required to be of the same type.

Can anybody advise me on these issues? Perhaps using pointers (ugh!)?

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Obviously I messed up the syntax-highlighting feature. I wish there were a way to preview your submissions!

I fixed the post formatting for you.

EQUIVALENCE is still in the standard. It's a perfectly acceptable way of doing this. Your use of CALL was not legal in F77, but most F77 compilers didn't catch the error. (You could do it in modern Fortran if you didn't have explicit interfaces and disabled interface checking.)

I suppose one could use "pointer casting" with C_LOC and C_F_POINTER.

Retired 12/31/2016

It may still be in the standard, but a lot of info I can find (including three texts and any number of websites) say the EQUIVALENCE statement is "deprecated," meaning it is likely to be removed, that it is there only for backwards compatibility, and that we should try to avoid it in favor of "better" alternative that exist. It seems to me there are no alternatives at all, let alone better ones. (I do understand that EQUIVALENCE was perhaps largely abused in the past, but there are still very useful legitimate uses for it, and the standards committee is taking heat for throwing the baby out with the bathwater in deprecating it. I hope that Intel does not support any future decision to follow through on removing it.)

In the meantime, getting back to part 1 of my original inquiry, what recourse do I have if the storage space needs to be dynamically allocated? Should I just dismiss that tempting feature? 

use, intrinsic :: iso_c_binding
real, pointer, dimension(:) :: ap
call c_f_pointer (c_loc(z), ap, [apts])

Now ap is an array of reals, with dimension (apts), that shares storage with z. z can be dynamically allocated. You should give z the TARGET attribute.

Intel won't remove any feature that was in Fortran 77 or later.

Retired 12/31/2016

Just for luck, I googled for equivalence deprecated, and the Fortran usage doesn't even make the first page of hits.  Then, the first hit which refers to Fortran proposes avoiding equivalence passing an array twice to  a subroutine, which seems to make it nearly impossible to analyze whether the standard is violated.

I'm having difficulty understanding why TRANSFERring a pointer to create multiple views of an array would be more desirable than EQUIVALENCE which to me specifies the intent more directly.

If you're using static allocation, EQUIVALENCE is fine. For dynamic allocation, you can't use EQUIVALENCE so using pointers is better.

Retired 12/31/2016

The use of TRANSFER as suggested by some as a substitute for EQUIVALENCE is ridiculous. The former requires some finite time and twice the memory. The latter requires 0 time and 0 additional memory.

Re Intel never removing EQUIVALENCE, I appreciate that. My concern is not Intel's practice, but everyone else, in efforts to conform to the Standard. In other words, it behoovs us (and everyone I think) to strive for portability, and the only way this can truly be accomplished is to have the Standard as a set of minimum requirements that every vendor is forced to conform to. I'm sure that many users have run into trouble by using extensions in old programs--in some cases without even realizing they were extensions, and in some by assuming that they would simply continue as de-facto "standards."

An example would be the PAUSE statement. We used this routinely in our old (console) applications, dating back to MS 5.1. Then it was deprecated, and eventually removed. Intel still supports it as an extension. Our old compiler has migrated from MS to Digital to Compaq to Intel. Who knows what next? And many, many users have moved, either by choice or by force, to simply switch vendors. It takes a lot of time to develop programs in Fortran, and we expect them to have a much longer lifetime than those written in other "modern" (disposable-code) languages. Who knows what the future will bring? I can't be guaranteed that my use of PAUSE will continue to run without hiccuping, since it is no longer in the Fortran Standard. If I believe 100% in portability, I would have no choice but to look for an alternative to PAUSE and EQUIVALENCE. But I won't, in the case of EQUIVALENCE, because I don't think there is a good alternative.

I've spoken with representatives from quite a few commercial vendors, and all of them say that they have no intention of removing once-standard features. Not only would this annoy customers, but it's a pain for us as well to do that. We'd rather spend the time adding language features. In fact, vendors are consistently on the side of NOT deleting features.

Continue to use PAUSE and EQUIVALENCE if they make sense for you.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today