forums.silverfrost.com

[DanRRight]

[mecej4]

The loop count is calculated just once, when the DO construct is begun. Subsequent changes to the variables used in the <start>, <end> and <increment> expressions do not affect the loop count. However, such changes can affect whether a premature EXIT, or a CYCLE statement, are executed.

See davidb's post of Feb. 20 in http://forums.silverfrost.com/viewtopic.php?t=3682 .

Over the years, working with codes that were decades old, I have seen DO index variables abused quite a bit. In one code, the DO index was passed as an argument in a subroutine call inside the loop, and the subroutine changed the value of the index variable.

If you want a free-wheeling DO loop, you may use a

DO WHILE(<condition>)
<statements>
END DO

block, or a plain

DO
<statements>
END DO

construct.

[DanRRight]

If you look at this example of DO loop which is a sibling of my example above with "classical" DO loop of Fortran-66 era or even before that you can see that its finishing condition is calculated every time with no problems.

[mecej4]

[DanRRight]

Mecej4, DavidB did not discuss explicitly possibility of dynamic changing start and end of DO loop. We even discussed here ones the possibility of dynamic changing DO loop variable i like in

DO i=iStart, iEnd

and there were no strict opposition for that besides the rulings of the Standard. Heard there exist other than Fortran compilers which allow dynamically changing even all three: i, iStart and iEnd. I'd probably agree with not allowing for using floating point numbers for them as this has hidden problem with the rounding of FP numbers but still do not see reasons for the restrictions we are discussing above

[JohnCampbell]

Dan,

The change to DO loop cycles was one of the more significant changes at F77. It has become a significant property of Fortran DO loops.
If you want to vary the loop cycles, you have "DO while" or use "DO" and manage the loop variable and exit.

John

[mecej4]

[DanRRight]

[davidb]

The standard says:

"The number of iterations of a loop may be determined at the beginning of execution of the DO construct, or may be left indefinite ("DO forever" or DO WHILE). In either case, an EXIT statement (8.1.4.4.4) anywhere in the DO construct may be executed to terminate the loop immediately."

It also says:

"Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither be redefined nor become undefined while the DO construct is active."

The standard doesn't forbid changing m1, m2, or m3 in the loop as far as I know, but such changes don't affect the number of loop iterations. They can't because the number of iterations is calculated at the beginning, before the loop is executed.

Knowing the number of iterations up front allows optimizing compilers to optimize the loop effectively (techniques as loop-unrolling, swapping loops, merging loops).

The loop

[DanRRight]

DavidB,

Great, since the only serious negative objection from dynamic changing iStart, iEnd and iStep (and probably even loop variable i itself DO i=iStart, iEnd, iStep) could potentially be difficulties of compiler optimization (not always necessarily so, sure by far not) then from this follows pretty satisfactory solution for both sheep and wolves:

1) Users who change these variables dynamically get the compiler warning "Dynamically changing DO loop controlling variables may prevent compiler optimization"

2) As an extension of Standard, all DO loop controlling variables are not just calculated ones before the loop start but can be changed dynamically at any moment during its run.

How about that?

[mecej4]

Dan, the title of the thread is misleading. There is nothing "illegal" about the short example code that you started with. Your complaint is really about how the loop is executed. You expect different behavior than what the standard prescribes.

If you want your request to be taken seriously, you will need to do far more work to prepare and justify your request. You will need to consider all possible circumstances and variations, write down a precise and complete prescription of how the loop ought to behave, why your proposed interpretation of DO would be better than the present behavior, and explain why you think that your requested behavior should be imposed on everyone. You should also be prepared to do a cost versus benefit analysis, and to justify why you do not want to use the already available DO WHILE facility.

[JohnCampbell]

[mecej4]

John, if we let Dan build castles in the air, he could one day demand that the optional increment expression (the i3 in DO i = i1, i2, i3) should be allowed to be changed in the loop; if that change involves i3 = -i3, Dan will have created an UNDO loop lurking inside a DO loop!

[DanRRight]