# Re: storing an integer in a double precision

"gmail-unlp" <ftinetti@xxxxxxxxx> wrote in message

On May 6, 6:43 am, "robin" <robi...@xxxxxxxxxxxxxxxxxx> wrote:
<tho...@xxxxxxxxxxxx> wrote in messagenews:iq0c0l\$tsu\$1@xxxxxxxxxxxxxxxxxxxx
| steve <kar...@xxxxxxxxxxx> writes:

| > program foo
| > integer i, j
| > double precision, volatile :: d
| > print *, 'Range: ', -huge(i), huge(i)
| > do i = - huge(i), huge(i)
| > d = i
| > j = d
| > if (i /=3D j) print *, i, j, d
| > end do
| > end program foo
|
| Any chance that an optimizer might just replace d=i and j=d
| with j=i? I'm guessing no.

No, but it might say that you're wasting computer time. :-)
The loop may never finish.

Why
The loop may never finish.
?

Because:-

program test
implicit none
integer :: i
do i = huge(i)-5, huge(i)
print *, i
end do
end program test

2147483642
2147483643
2147483644
2147483645
2147483646
2147483647
-2147483648
-2147483647
-2147483646
-2147483645
-2147483644
-2147483643
-2147483642
-2147483641
..

.

## Relevant Pages

• Re: R: Re: Strange behaviour with numerical precision
... Or, alternatively, how do I perform a high precision ... number is smaller than the low-precision, the low-precision calculation ...
(comp.lang.fortran)
• Re: calculation accuracy
... DOUBLE PRECISION:: PI_D ... END PROGRAM test ... in fortran is quite a bit different than what I get in excel. ...
(comp.lang.fortran)
• use of EQUIVALENCE in fortran 90
... double precision:: A ... end program test ... Of course I could skip the EQUIVALENCE statement, allocate both A and x and then use e.g. ... I think the best solution would be to avoid this kind of things at all, but I'd like to know if there is a more modern way of achieving the same result as the old EQUIVALENCE without using twice the memory. ...
(comp.lang.fortran)
• Re: Pi.
... I agree with the approach -- compute pi to the requested precision rather ... than depend on a stored constant. ... end program test ... > 95 but not Fortran 2003). ...
(comp.lang.fortran)
• Precision of real numbers
... I meet a strange problem regarding precision of real numbers. ... END PROGRAM TEST ... The last digit of the third output is not right. ...
(comp.lang.fortran)