Phillip Helbig writes:
 > I think it makes code less readable to specify kind values on literals.  
 > It would be nice to be able to alter the default kind for literals 
 > within a scoping unit.

Yes.  Quite a few people have asked for that.  It was even accepted as
a minor technical enhancement by the committee at one time.  (I forget
whether for f95 or f2k).  That categorization means that it is a
desired feature, but only if it is "low cost".  It is the
responsibility of the people pushing it to complete the job in a
satisfactory manner so that it can get in.  If they don't get it done,
then the standard goes ahead without it.  The person who took this on
found it more difficult than he expected, so it didn't get done.  And
I think the reason that nobody else stepped in was that they thought
it was a bit much work.  There are an awful lot of places in the
standard that I suspect it would impact.  Not that I think it is
probably difficult in any real sense - but a lot of grubby work.  A
grep of the standard for the word "default" is probably going to get a
huge number of hits, pretty much all of which would have to be at
least looked at, and a fair number of which might need to change.

 > Many folks have the impression that DOUBLE PRECISION has been superseded 
 > by the KIND mechanism.  Sure, KIND can do more stuff, but am I mistaken 
 > that there are some applications where the RELATIVE precisions are more 
 > important?  For example, some subroutine deep down might want to use 
 > higher precision than the stuff the user is interfacing with, 
 > independent of the actual precisions involved.

Sure there are.  But double precision doesn't help with that in any
general sense.  Double precision can do that only if the first kind
was single precision.  That's very restrictive.  The kind syntax, on
the other hand, can do that for arbitrary precisions, as long as the
system supports the required precisions.  We've seen examples here
before.  I'll probably mess it up off the top of my head, in which
case I'm sure corrections will be given, but something like

  real(working_kind) :: x
  integer, parameter :: higher_kind = selected_real_kind(precision(x)+1)

You might be able to get fancier and ask for a higher precision if
available, settling for the same kind if it's already the highest,
but I don't think I'll try the trick of writing that as an
initialization expression.  (Probably doable, but also probably
ugly.  I might be tempted to just make it a system-dependent
parameter and hand-set it in a system-dependent module).

For my part, I never use double precision declarations in f90 code.
If I really wanted double precision, I'd still use the kind syntax
and use the rd_kind parameter from my precision module.  This
code lifted right out of the module I normally use - though I far
more commonly use some of the other parameters from the module.
(Most on the list will probably recognize the derivations of
several of my parameter names).

!-- 4 Mar 92, Richard Maine: Version 1.0.

module precision

  !-- Kind constants for system-independent precision specification.
  !-- 4 Mar 92, Richard Maine.

  implicit none
  public

  !-- System default kinds.
  integer, parameter :: i_kind = kind(0)      !-- default integer
  integer, parameter :: rs_kind = kind(0.)    !-- real single precision
  integer, parameter :: rd_kind = kind(0.d0)  !-- real double precision

  !-- Kinds for specified real precisions.
  integer, parameter :: r4_kind = selected_real_kind(6,30)   !-- 6 digits
  integer, parameter :: r8_kind = selected_real_kind(12,30)  !-- 12 digits

  !-- Kinds for specified integer ranges.
  integer, parameter :: i1_kind = selected_int_kind(2)  !-- 99 max
  integer, parameter :: i2_kind = selected_int_kind(4)  !-- 9,999 max
  integer, parameter :: i4_kind = selected_int_kind(9)  !-- 999,999,999 max

  !-- Kind for working real precision.
  integer, parameter :: r_kind = r8_kind

....more stuff of less relevance.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%