Hello,
> No. It is likely to be like assumed-length character.
By what you have said (especially using the term dope vector), it sounds to
me more like assumed-shape arrays, especially since I gather one can defer
the nonkind type parameters in allocatables and pointers (right?), which one
cannot do with (F95 at least) assumed-length character (not talking
variable-length strings, which might be in F2x? (have not read character
stuff as don't really care)).
The importance of this for me was that is one uses the above point type in a
routine (some of the syntax may be off here):
type :: point(r_kind,dim)
integer, kind :: r_kind
integer, nonkind :: dim
real(r_kind) :: coords(dim)
end type point
subroutine translate_point(x,shift)
type(point(r_sp,*)), intent(inout) :: x
real(r_sp), dimension(*) :: shift
x%coords=x%coords+shift(1:x%dim)
end subroutine translate_point
then though the routine is highly elegant it is not what one should really
use in practice for efficiency. In practice, we only use dim=2 or dim=3, or
*ocassionaly* others, so one should make translate_point a generic and have
separate routines for dim=2 and 3 (so the compiler knows that the x%coords
array is small and optimizes it maximally, as opposed to adding a loop there
or something alike), and one general for other dimensions.
Can nonkind type parameters be used to resolve generics, i.e. can one do what
I suggest in the paragraph above in F2x?
> The dim is neither internal to the structure nor known at compile
> time. Those are not the only two options. The dim is likely to be
> passed as part of a "dope vector".
The point here is that there are two possibilities, which are as far as I see
them *radically* different. One is a scheme in which the array coords is
*part* of the structure, i.e. the space that the type point occupies will be
dim*size_of_real, which will be different for different dims (and the
compiler might pad or reorder the type differently for different dims, which
is why I thought it would know everything at compil-time). The other scheme
is one in which coords is really a pointer to an externally allocated and
stored array. It was my impression that it was the first scheme which this
whole business of nonkind parameters was geared toward. In fact, this is what
I would ask for as a user (especially one that writes simulations that are to
work in 1, 2 and 3 dimensions).
But now I am thinking I am in error? I know the standard does not always
prescribe these things, but what was J3's expectation of how this would be
implemented in real life?
Thanks again,
Aleksandar
--
__________________________________
Aleksandar Donev
Complex Materials Theory Group (http://cherrypit.princeton.edu/)
Princeton Materials Institute & Program in Applied and Computational Mathematics
@ Princeton University
Address:
419 Bowen Hall, 70 Prospect Avenue
Princeton University
Princeton, NJ 08540-5211
E-mail: [log in to unmask]
WWW: http://atom.princeton.edu/donev
Phone: (609) 258-2775
Fax: (609) 258-6878
__________________________________
|