Re: whole number constants

dancerchris@xxxxxxxxxxxxx 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
.