Re: whole number constants

robin wrote:
> "Dick Hendrickson" <dick.hendrickson@[EMAIL PROTECTED]
> wrote in message
> news:he7hk.129353$102.58099@[EMAIL PROTECTED]
>> dancerchris@[EMAIL PROTECTED]
 wrote:
>>> This may be a dumb question but what is "best practice" when coding
>>> whole numbers in real (kind specified) formulas.  I am looking for
>>> accuracy, consistancy and prortability reagardless of what value dp
>>> has below.  Many of my calcs have numerical cancellations or accuracy
>>> checks as per the error function below.  What are the pitfalls?
>>>
>>> for example:
>>>
>>> integer, parameter :: dp = selected_real_kind(15, 307)
>>>
>>> real(dp)  :: x,xnew
>>>
>>> real(dp), parameter :: one = 1.0_dp
>>> real(dp), parameter :: onend = 1_dp
>>> real(dp), parameter :: onenk = 1.0
>>> real(dp), parameter :: onei = 1
>>>
>> For real constants that are exact integers and are small enough
>> to fit in one word, those 4 are (almost) exactly equivalent.
>> No processor in the world will possibly mess up the conversion
>> of 1 or 1.0 or 1.0_dp into some other kind.  My advice would
>> be to do what looks natural, as long as you declare the result
>> kind, via the "real(dp)".
>>
>> The interesting exception here is the "1_dp" form.  This
>> declares an integer of kind dp.  It's not guaranteed that
>> this will be ****table.
> 
> It's worse than that.
> 
> It isn't correct, and may appear to execute OK
> on some systems.
> If you are lucky, a particular compiler may issue
> an error message because that kind doesn't exist
> among the kinds of integers.
> 
I don't know what you are trying to say here, possibly
you don't recognize 1_dp as a valid way to write an integer
of kind "dp".

If "dp" has a value that is a sup****ted integer kind on
a processor, then surely the processor will get the value
of "1" correct.  There is simply no (even semi-)successful
processor that can't represent small integers correctly.
If "dp" isn't a sup****ted integer kind, then the processor
is required to issue an error message.

The issue is purely ****tability.  Using selected_real_kind
is an unusual way to compute an integer kind value.  On
32 bit machines, the value of "dp" is likely to be the
double precision real kind value.  Most processors use
the same kind values for integers and reals of the same
size.  On those processors, if they don't provide 64 bit
integers, they'll have to issue an error.  It's all
clearly specified by the standard.  (Except for the
fact that the standard doesn't require compilers to sup****t
integers with values as large as 1 ;) ).

Dick Hendrickson