Yes, adding a kind selection capability based on byte size would allow you
to choose what you care about most, and would return control to the
developer on this issue. And having a sizeof equivalent is pretty much a
no-brainer to me. Interesting points though; thanks! - Bob
----- Original Message -----
From: "Joe Krahn" <krahn.niehs.nih.gov>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, March 31, 2009 1:50 PM
Subject: Re: [AMBER-Developers] Usage of long symbol names, KIND, DFLOAT,
etc.
> They have become only slightly less clueless. But, the people that had a
> clue were out-numbered and left. KIND values are still abstract. The one
> advantage is that you can use the ISO C Binding features to match C types,
> such as double and int32_t.
>
> The stubborn rationale about the abstract KIND is that a system could
> theoretically have 2 different floating representations using the same
> byte size. In particular, there is more than one form of quad-precision
> currently in use. Also, character KINDs could indicate different character
> sets, but nobody actually uses character kinds yet.
>
> Of course, there is no reason not to have a KIND selection function based
> on byte size, and no reason not to have a standard SIZEOF() function.
>
> 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:40 PDT
