[J3] [BULK] Re: [EXTERNAL] Complex pointer to real array and vice-versa

[Malcolm Cohen]

Hi Brad and Tom,

(1) the definition of type COMPLEX says it is an ordered pair, with the first part being the real part and the second part being the imaginary part. I suppose one could pretend that those words are only talking about the philosophical value, not the representation, but that's not very helpful.

And then one realises that that pretence would render old programs that EQUIVALENCEd or COMMONed REAL and COMPLEX non-conforming, because if the standard does not establish which part is %RE and which part is %IM, it thereby fails to establish an interpretation of the program. And that would violate our compatibility clauses which say that those programs remain conforming. And so that pretence is not just unhelpful, but also incorrect.

That argument only applies to default COMPLEX, of course.

 (2)
Tom writes:
> I’m not 100% certain that the standard disallows a complex representation in terms of modulus and phase.

I am. Given a COMPLEX(any kind) TARGET and REAL(same kind) POINTERs to the %RE and %IM parts, one can assign to/from the COMPLEX and REAL interchangeably and observe that assigning (1,2) ends up with the %RE pointer being equal to one and the %IM pointer being equal to two. This cannot happen if you have modulus/phase representation.

Cheers,
-- 
..............Malcolm Cohen, NAG Oxford/Tokyo.

-----Original Message-----
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Brad Richardson via J3
Sent: Friday, April 26, 2024 12:03 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Complex pointer to real array and vice-versa

My reading is that there is a very subtle way in which the rules are not quite sufficient to guarantee correct data interpretation of storage sequence association between real and complex arrays of all kinds, but all sane (and actual as far as I know) implementations would work. This would fully close off the possibilities of using alternate data layout/interpretation strategies, but I don't think that's really going to negatively impact anyone.

My hesitation for the proposal is that it is a subtle violation of the type-safety of the language, but just barely and it is well constrained. That's just the purist in me talking though, so it's by no means a strong objection.

Regards,
Brad

On Thu, 2024-04-25 at 13:19 +0000, Clune, Thomas L. \(GSFC-6101\) via
J3 wrote:
> 
> 
> 
> I think the requirement for COMPLEX and REAL storage association is 
> stronger than you have suggested:
>  
> 19.5.3.2:    …  (2) a nonpointer scalar object that is double 
> precision real or default complex occupies two contiguous numeric 
> storage units,
>  
>  
> 
> 
> 
> 
> 
> 
> 
> From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Pierre 
> Hugonnet via J3 <j3 at mailman.j3-fortran.org>
> Date: Wednesday, April 24, 2024 at 4:41 PM
> To: Van Snyder via J3 <j3 at mailman.j3-fortran.org>
> Cc: Pierre Hugonnet <pieru at ugo235.fr>
> Subject: [BULK] Re: [J3] [EXTERNAL] Complex pointer to real array and 
> vice-versa
> CAUTION: This email originated from outside of NASA.  Please take care 
> when clicking links or opening attachments.  Use the "Report Message" 
> button to report suspicious messages to the NASA SOC.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hello,
> 
> 
> Le 23/04/2024 à 21:55, Van Snyder via J3 a écrit : 
> 
> > Specific comments on the paper:
> > 
> > Section 3.1 need not mention the "target or the pointer attribute"
> > because pointers have the target attribute.
> 
> 
> In `c => r` (or any alternative syntax), `r` is not necessarily a 
> pointer array, it can be a static array, an allocatable array, etc...
> So it seems to me that "... with the target or the pointer attribute"
> is correct. But maybe I didn't catch your point...
> 
> 
> > 
> > Section 4.1 would not constrain the memory layout any more than 
> > equivalence already does. The required layout does not "seem to be 
> > the de-facto standard." It's what's already required to make 
> > equivalence work.
> 
> Well, yes and no... EQUIVALENCE is defined for the default complex 
> type only, and anything could happen with the other kinds. If a 
> compiler stores the `double precision` type on 8 bytes, I think that 
> nothing in the standard would disallow storing a `complex(kind(1d0))` 
> on 20 bytes for instance. I doubt any past or existing compiler did or 
> does that, but it would be allowed.
> 
> Also, and even for the default complex type, I think that the current 
> standard allows storing the imaginary part first, and the real part 
> second. With the new proposal, the real part would necessarily come 
> first (which is the "de facto standard" anyway).
> 
> 
> 
> > 
> > 
> > Yeah, people want to eliminate storage association, but it's still 
> > in the standard. This proposal would be concistent with it, and 
> > would not change it.
> 
> My personal opinion is that storage association can still make sense 
> in some cases in HPC (typically when dealing with large/huge data
> volumes)
> 
> 
>  
> 
> 
>  
> 
> 
> Regards
> 
> 
>