(j3.2006) Finalization ordering question
Mon Oct 22 17:49:18 EDT 2007
Malcolm Cohen wrote:
> I'm not really following this, but anyway...
> Array%Scalar is a well-recognised idiom since F90 (there are even
> examples in the standard).
> Bill originally said:
>> 188.8.131.52 seems to say the finalizations has to be done in this order:
>> Step 2: x(1)%fe, x(2)%fe, x(3)%fe
>> Step 3: x(1)%ft, x(2)%ft, x(3)%ft
> There is nothing in 184.108.40.206 about array element ordering, so I think this
> is clearly (maybe obviously) processor-dependent. In fact if there are two
> components that have final subroutines (say FE and FE2), the wording in
> 220.127.116.11 allows Step 2 to be done in the order
> FE of x(1), x(2), x(3) then FE2 of x(1), x(2), x(3)
> FE of x(1), FE2 of x(1), FE of x(3), FE2 of x(2), FE of x(2), FE2 of x(3)
> etc. Admittedly that part of the wording is less clear, but I don't see
> an ordering requirement there. As to whether it is better to interleave
> the procedures or the array elements, I'd say it depends.
Right. I meant the ordering only in the vertical direction (Step 2
before Step 3). However, I'm not yet completely clear on the intention
of the requirement in Step 3 that "the parent component is finalized".
In this example, is the parent component finalized by a single call to
the rank-1 final routine for type ft, with argument x(:)%ft, or is it
finalized by three calls to the scalar final routine for type ft? Step
2 explicitly lays out when arrays are chopped into elements to be
finalized separately, but Step 3 does not.
> Personally, I'd probably lean towards having the order processor-dependent:
> sometimes depth-first is best, sometimes breadth-first. But that might be
> inconvenient for some users... on balance I'd rather not go back into the
> finalization swamp sifting through the various conflicting options and
> opinions to reexamine our choice of what we thought was the best way out
> at the time.
Processor-dependent sounds nice to me, but only if I'm sure it is not
ambiguous. Since final routines for different ranks can have different
effects, it's dicey to be too processor-dependent.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3