Topic: code.f do loop with real values warning

I have code that has a do loop that gives this warning.

            DO 50  RMU = 0.0, 1.0, 0.01                                 
                 1
Warning: Deleted feature: Loop variable at (1) must be integer

What should I do?
Thanks

  • jeff
  • Administrator
  • Offline

Re: code.f do loop with real values warning

The message is only a warning, so you can leave it as is.  I have plenty of code that causes this warning to appear myself.  However, to get around it, you'd probably do something like:

       DO 50  IRMU = 0, 100
           RMU = REAL(IRMU)*0.01 
           ...

The above would be technically correct.  However, I tend to just ignore that warning myself.

Jeff Armstrong
Approximatrix, LLC

Re: code.f do loop with real values warning

Some history:

Real valued indices for DO loops were allowed in Fortran 77. However, this feature was removed in Fortran 90.

If you want to remove the warning completely then you can use the option

-std=legacy or enforce the legacy standard in Project Options in Simply Fortran's GUI.

Though Jeff's code will work, I prefer the following alternative, which gives RMU the correct value after the loop and eliminates the multiplication.

RMU = 0.0
DO IRMU=1, 101

    ! Original loop body

    ! Increase RMU at end
    RMU = RMU + 0.01

END DO
--
David
  • jeff
  • Administrator
  • Offline

Re: code.f do loop with real values warning

davidb wrote:

Though Jeff's code will work, I prefer the following alternative, which gives RMU the correct value after the loop and eliminates the multiplication.

Ah yes, David's code would definitely be preferable.

Jeff Armstrong
Approximatrix, LLC

Re: code.f do loop with real values warning

Sorry, but in scientific computing, we usually prefer the Jeff's solution. For two reasons:
1) Today, floating-point multiplication and addition have very close latencies. See for example the discussion in:
    http://stackoverflow.com/questions/1146 … t-multiply
    In the past, the old FORTRAN programmers were used to write
    

x = a + a

    instead of
    

x = 2*a

    but the first layout is less clear than the second one. The reason was only performance. It makes no sense today...
2) The Jeff's solution, which compute RMU directly will not lead to roundoff errors!
    Generally speaking, avoid a long summation of floating-point numbers, otherwise there is a great risk to obtain the last value
    greater than that expected. In some situation (a function defined only on a given interval), this may be critical.