From: sumesh.pt on
In mixed mode operations, is it advisable to convert integers to
double using the command dble() in the expressions or would it be
better for the compiler to do this job? I am asking this NOT from the
point of view of understanding the program easily, but in terms of
speed and accuracy. ie
real*8 :: x
integer :: i=10
x = x/i or x=x/dble(i) which is faster and accurate.

I am doing some kind of recursion calculations with x and hence error
gets accumulated and I am not able to decide which is best.

Thanks,
From: Tim Prince on
sumesh.pt wrote:


> In mixed mode operations, is it advisable to convert integers to
> double using the command dble() in the expressions or would it be
> better for the compiler to do this job? I am asking this NOT from the
> point of view of understanding the program easily, but in terms of
> speed and accuracy. ie
> real*8 :: x
> integer :: i=10
> x = x/i or x=x/dble(i) which is faster and accurate.
>
> I am doing some kind of recursion calculations with x and hence error
> gets accumulated and I am not able to decide which is best.
>

I see no reason for this to make a difference. You could check the asm
code generated by your compiler, since you appear to be interested. If
you do this in a context where the compiler may have the option to
replace x/i by x*0.1d0, that replacement should increase performance,
with a possible slight reduction of accuracy. With certain well-known
compilers, if you choose compile flags which avoid this replacement, the
similar replacement of x/8 by x*.125d0 may also be suppressed, even
though that one doesn't affect accuracy, so would have been a clear gain.
From: glen herrmannsfeldt on
sumesh.pt <sumesh.pt(a)gmail.com> wrote:

< In mixed mode operations, is it advisable to convert integers to
< double using the command dble() in the expressions or would it be
< better for the compiler to do this job? I am asking this NOT from the
< point of view of understanding the program easily, but in terms of
< speed and accuracy. ie
< real*8 :: x
< integer :: i=10
< x = x/i or x=x/dble(i) which is faster and accurate.

For the same conversion, the speed and accuracy should be
the same. There are some cases where you might want a different
conversion, in which case the functions are useful.

< I am doing some kind of recursion calculations with x and hence error
< gets accumulated and I am not able to decide which is best.

If, for example, you wanted to divide a default REAL (not double
precision) by an integer, but with the division done in double
precision, then you might need a conversion function.

In Fortran 66 days DFLOAT was used to convert integer to
double precision. It seems that DBLE now will do that.

There used to be questions about constant conversion at compile
time vs. run time. That is, x/2 vs. x/2.0. I believe by now
all compilers should do that at compile time, but it used to
be a big discussion topic.

-- glen
From: e p chandler on
On Sep 9, 9:36 pm, "sumesh.pt" <sumesh...(a)gmail.com> wrote:
> In mixed mode operations, is it advisable to convert integers to
> double using the command dble() in the expressions or would it be
> better for the compiler to do this job? I am asking this NOT from the
> point of view of understanding the program easily, but in terms of
> speed and accuracy. ie
> real*8 :: x
> integer :: i=10
> x = x/i    or    x=x/dble(i)   which is faster and accurate..

In general for integer constants it should not make a difference.
However, do not expect a real constant to be promoted to a higher
precision because it is in a mixed mode expression or it is assigned
to a variable of higher precision. Instead specify, for example,
9.237543521d0 (or the appropriate kind _ suffix).

> I am doing some kind of recursion calculations with x and hence error
> gets accumulated and I am not able to decide which is best.

That is a different story. Errors tend to accumulate in using
recurrence relations. Sometimes the recurrence is quite sensitive to
the direction in which it is calculated. A good text on numerical
analysis should cover this.

The short version is I suspect you have an algorithm problem rather
than a Fortran problem.

-- elliot
-- email: epc8 at juno dot com


From: sumesh.pt on
Thanks a lot for all the inputs. It indeed helps me now.

sumesh