Re: whole number constants

dancerchris@[EMAIL PROTECTED]
 wrote:
> p.s.
> 
> I know for the stuff that I am doing that label 100 is safe practice
> and works well.
> 
> I was trying to be a little more compact/ledgable with the coding with
> preferably something like label 300.  The problems I have run into are
> generally with error functions and comparison of like values between
> subroutines/functions, but I think it is perhaps overly conservative
> to specify a parameter for a whole number rather than use coding like
> label 300

The fact that you're confused about what is and isn't the same suggests
you should stick 
to what you know is "correct" (still trying to understan the differences
though, of course 
:o). You should code defensively and think about the people that will come
after you, not 
just how pretty you want the code to look. If you are confused as to
whether

   100 error = one-xnew/x+one
   200 error = 1.0_dp-xnew/x+1.0_dp
   300 error = 1-xnew/x+1

are consistent, chances are so will future maintainers of the code. You
taking five 
minutes to be crystal clear about what you're doing will save them a lot
more time if the 
same question occurs to them.

I prefer the form

   real(dp), parameter :: one = 1.0_dp
   ....
   100 error = one-xnew/x+one

because it is pretty much completely unambiguous. So is the second one
(200) if you don't 
mind typing the kind type suffix all over (it may not always be nice and
short like "dp"). 
The third one (300) is o.k. if you're always going to stick to whole
numbers like 1. But 
if you get into the habit, you could end up doing something like,

   integer, parameter :: dp = selected_real_kind(15)
   real(dp) :: var, x, y
   ....
   var = 0.1 + x/(y - 0.15)

where now the literal constants are not represented to the same precision
as the variables 
are typed because you've specified them only to single precision.

If you're in the business of writing tangent-linear and adjoint forms of
models, these 
little precision hiccups can add up.

cheers,

paulv