"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.
> 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.
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.
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.
> 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 ;) ).
|
