I am of the opinion that fighting over maximum name lengths is a waste of
time, and completely contrary to the flow in evolving good software
engineering practice. I suppose that if I were to see a fortran compiler
that patently fails on some >n name length, I would feel otherwise. But in
general, descriptive names are good, though of course there is a tradeoff
and some common sense involved. If you wanted to legislate on name length,
I would legislate against single character names, with the possible
exception of loop counters, and even there I tend to use slightly
descriptive names.
On kind params, I get kind of ill over the lack of standardization as to
what a kind of type n implies. It is an open invitation to disaster,
foisted on us by abstractionists without a clue what it means to write code
closer to the system - what I am whining about here is basically there is no
good way to know how much memory is actually being used, and that can really
matter. Okay, so how to deal with the "kind" mess? The best solution I
have is to use selected_int_kind() and selected_real_kind(). What these do
for you is look up a kind param that can represent numbers over some range
(so I use selected_int_kind(2) to get a byte because this type is guaranteed
to support a value over the range of -100 to 100. I then parameterize this
to the name "byte" (see gbl_datatypes.fpp in pmemd). Is this foolproof? I
don't think so, in that if you had a machine architecture that could not
handle 1 byte integers, they might map this to something larger than 8 bits.
Why do I care? Well, depending on how you interface with mpi, system code,
and c code, you might get in a mess over data sizes. In general 4 vs 8 byte
stuff is handled explicitly by compiler switches, so I tend to not worry
about 4 vs 8 byte integers. Joe, I would be interested to know if they have
done anything about this in fortran 2003; I have not looked yet, and in
general have not been interested because I don't want to force adoption of
something that recent (never inconvenience your user for your own
convenience...). Early on in doing f95 code, I encountered definite cases
where assumptions about kind mapping to byte length were violated by some
compilers. You COULD explicitly map defined constants for kind types for
different compilers, require specification of the compiler by a defined
constant, and then you would be fine aside from the fact that the compiler
guys could change the kind types on you, and in addition you would not
automatically support any new compilers.
On the topic of "what the fortran standards want me to do", one does need to
keep in mind that the fortran standard, while somewhat improved, is still a
mess...
Doesn't everybody already use dble()?
- Bob
----- Original Message -----
From: "Joe Krahn" <krahn.niehs.nih.gov>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, March 31, 2009 12:27 PM
Subject: [AMBER-Developers] Usage of long symbol names, KIND, DFLOAT, etc.
> What is AMBER's position on the use of names longer than 31 chars? It
> violates the F95 standard, but maybe all supported compilers allow long
> names. F2003 increases the limit to 63 characters. Names longer than 31
> may sound a bit ridiculous, but it does make sense to use verbose names
> for globals. Mark just updated the charmm code using a 32-character name:
> CHARMM_ATOM_TYPE_NUMERICAL_LABEL.
>
> Some code uses the function DFLOAT(). It is not part of Fortran95; was it
> ever standard Fortran? Code should use DBLE() instead. However, DFLOAT is
> very common. Maybe it is OK to be lenient with this sort of very common
> extension.
>
> Complex declarations are a bit more of a problem. The Fortran Standards
> really want to push the KIND concept, and DOUBLE COMPLEX is no longer
> valid. Instead, you have to use COMPLEX(KIND=8). It still supports DOUBLE
> PRECISION. I suppose they didn't like double-complex because it is not as
> descriptive; it sounds a bit like "twice as complex".
>
> I would rather just use a KIND parameter, because that it what the Fortran
> standards want me to do. Alternatively, I can just put a #define _COMPELX_
> in dprec.h.
>
> Also, why is dprec.h in several places? Shouldn't there be a common AMBER
> include directory?
>
> Joe
>
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 01 2009 - 01:16:14 PDT
