LOOPS

Loops are a fundamental building block of most computer languages. Below are a few exercises designed to stretch your understanding of loops. Exercise 1 and 2 are trivial, but starting with exercise 8, a few twists and turns arrive that are all part of a day's work in the life of a REXX programmer.

Write a loop that lists the numbers from 1 through 50, then list their sum. [ * ]
Write a loop that lists the odd numbers from 1 through 51, then list their sum. [ * ]
Each language has rules, sometimes perceived as "quirks", about when variables are updated and exactly when the index of the loop (the number that varies) is incremented and checked. Explore these issues with the following REXX program:
```
/* Loop testing-1 */
SAY A
DO A = 1 TO 1
SAY "Top of Loop"
Say A
END
SAY A
```
Try lots of different ranges such as: 1 TO 0; 1 TO 4; 1 TO 10 BY 2; 10 TO 3 BY -2; etc. [ * ]
Now try a variation where the "index" (the variable tested at the end of each iteration) is varied inside the loop.

By the way, if you hate to type, did you know that Netscape allows one to copy and paste from a web page?
```
/* Loop testing-2 */
SAY A DO A = 1 TO 1 while B < 5
SAY "Top of Loop"
Say "A=" A "B=" B
B = A + 2
SAY "B=" B
END
SAY "END A=" A "B=" B
```
Try different ranges such as: 1 TO 1 While 0=0; 1 TO 4; 1 TO 10 BY 2; 10 TO 3 BY -2; etc. But first, you'll have to figure out why, as written above, the program may not work quite as you expected. There weren't any error messages because, as far as REXX is concerned, this is a perfectly logical program! [ * ]
Try the following bit of risky code. We say "risky" because the program may not always work as first envisioned.
```
/* Loop testing-3 */
SAY A DO A = 1 TO 11
SAY "Top of Loop"
Say A
A = A + 2
END
SAY "END=" A
```
Don't be afraid to try fractional values such as: 1.5 TO 4.2 BY 1.5

Note that if things get out of control, pressing <CTRL><C> will usually stop execution.
Explore some of the other loop operatives such as, ITERATE, LEAVE, FOREVER, and UNTIL. Test these operatives at the boundaries.
Write a program that lists the numbers from 1 through 49, listing them "5up" across the screen. (Yes, we know ending at 49 will add a bit of heartburn, but that is part of the fun. If necessary, you could try the routine first with 50, then deal with 49 or 46 as a separate exercise.)

example:

1 2 3 4 5

6 7 8 9 10

...
Now include row and column totals in exercise 8.
Repeat exercise 9, but arrange the output such that the columns "snake". (The numbers 1, 2, 3, etc. go down the columns.)
If you haven't already, format the above such that the columns are aligned nicely.
Generalize your routine such that when asked to generate a table with an arbitrary number of entries, you will only have to change a few variables and re-run the program. Can your program switch on or off the column and/or row totals? Can you change the number of columns?
Very nice, but what happens if there are so many rows in your table that they can't be displayed without scrolling the screen? Generalize your program such that, when necessary, the display will pause before the top row scrolls off the screen and ask the user for permission to continue with the next screen. [ * ]

If you need an example of how this might look, you can type the following Directory command at a DOS or OS/2 command prompt.

DIR \ /P /S

When you have seen enough, press <CTRL><C>
For extra credit consider the above if the range of numbers contains fractional values such as 1, 1.25, 1.5, 1.75, 2, etc. Do your decimal points line up nicely? What happens to trailing zeros? Should they be displayed or not? Can you control how many, if any, trailing zeros are displayed? Do all of your decimal points display? Should they? [ * ]
Could your generalized routine survive if the boss asked that the values be displayed in descending order or if the values crossed through zero? [ * ]

There is no one best way to attack the above tasks. While there may be "points" for clever programming style, there are no points if the program doesn't work.

Sometmes generalizing a program is not good use of your time. It's not worth spending several hours or more generalizing a "one shot" program that could otherwise be written in a few minutes. Everyone develops their own style. Experienced programmers automatically tend to write more easily generalized programs than do novice programmers. Sometimes the generalization saves time later when that "one shot" becomes a production program, other times it turns around and bites you because there could be a subtle error introduced by the generalization.

About these pages
Content updated: 07-09-2005 09:55am

Page building by:

Content updated
07-09-2005 09:55am

1	2	3	4	5
6	7	8	9	10
...