robin wrote:
> "Dick Hendrickson" <dick.hendrickson@[EMAIL PROTECTED]
> wrote in message
> news:uEmhk.130337$102.119999@[EMAIL PROTECTED]
>> 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".
>
> It's a valid way to write an integer kind of dp,
> which is why the error is not obvious in Fortran.
> As a float constant (as the user intended it to mean)
> it is an error.
>
>> 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.
>
> You are contradicing yourself.
How so? There are 2 cases, "dp" represents a sup****ted
integer kind value, or it doesn't. I described the
results for each.
>
>> 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.
>
> The fact that some might is irrelevant.
That's why I said "most" instead of "all"
> There is no requirement that they do so,
> nor is there any guarantee that an integer kind exists
> for the value "dp".
>
> The point is that 1_dp -- if it represents anything
> at all -- is that it is an INTEGER, not REAL as the OP
> intended. Used as an argument, the user is due for
> some surprises if it goes undetected.
Certainly true, but the whole discussion started out
with parameter statements where type conversion is
guaranteed to happen in the original post.
>
> The fact is that it is wrong, and as I said,
> if you are lucky, you might get an error message.
> And then, not even necessarily a sensible one
> drawing attention to misuse of the kind number.
>
> Another point on which you are wrong/misleading is your
> statement that "Most processors use the same kind values
> for integers and reals of the same size."
> There is no requirement that they do, and there
> are some compilers in which there is no relation
> whatsoever. In particular, in some the kind number of
> one-byte integers corresponds to the kind numbers of
> reals, etc.
>
>> On those processors, if they don't provide 64 bit
>> integers, they'll have to issue an error.
>
> Again that statement is misleading, as even if the compiler
> doesn't sup****t 64-bt integers, an error message
> is not necessarily produced.
This is totally wrong. Constraint C404 requires the processor
to issue an error message for 1_dp if dp does not indicate
a sup****ted integer kind value. In a way, that's the whole
point of the kind system. You're guaranteed to either get
what you asked for or get an error message saying you can't
get it.
Dick Hendrickson
>
>> 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 ;) ).
>
>
>
|
