# Flow Chart For a 'for' Loop In Python

sysprog, post #24
That must be why the shape was chosen for making flow-chart diagrams.
Yes (as the text on the card image indicates). The corner cut was there to ensure that the card reader could tell when a card had been placed in a wrong position for reading. '9-edge in face down' was the convention.

to understand the my code fully and to make notes I am trying to draw flow charts to compliment my code.
As a normal part of the development cycle, coding proceeds from the flowchart - which is language agnostic - not the other way around.

That being said, you're just trying to get a handle on code that you've already written. I'd suggest conforming to a standard, and unpacking complex-statements completely. F'rinstance...

FOR I=1 TO 10 BY 1 PRINT I**2 unpacks into something like....

PRINT SQUARES 1 - 10:
      I = 1 .
TOP-OF-LOOP.
PRINT I**2 .
IF   I < 10
THEN INCREMENT I BY 1 ,
GOTO TOP-OF-LOOP .
From post #1:
Many textbooks for programming languages don't even bother with flow charts, but use pseudocode instead.
Yes, no, maybe : the method I use/taught included both, at different stages of the development cycle.

Last edited:
.Scott
Homework Helper
The corner cut was there to ensure that the card reader could tell when a card had been placed in a wrong position for reading.
Not exactly. The card readers did not look for that cut. But the key-punch operators, computer operators, and programmers did.
By "card readers", I am including all manner of card reading devices: High Speed card sorters; 400-series accounting machines; reproduce punch machines; key punch machines; as well as computer card readers.
If you wanted to keypunch onto the back of the card (perhaps because you wanted to read the blank side), you could do that as long as you fed that card into the various card reading devices the same way. Of course, if you weren't the one actually feeding those cards to the machine, you would need to alert the computer operator to your deviant preference.
I worked with Data General, Honeywell and IBM card handling equipment. So there might be exceptions among Buroughs, Univac, NCR, CDC, and digital.

In general, card readers were not allowed to be picky. A lot of those cards were cycled through the target population (students, employees, applicants, teachers, administrators, ...) before being read. Those cards often came back with fairly creative damage.

Hey guys: Some of this information has been hanging around in my head for 50 years waiting to get out.

Klystron
Not exactly. The card readers did not look for that cut. But the key-punch operators, computer operators, and programmers did.
By "card readers", I am including all manner of card reading devices: High Speed card sorters; 400-series accounting machines; reproduce punch machines; key punch machines; as well as computer card readers.
If you wanted to keypunch onto the back of the card (perhaps because you wanted to read the blank side), you could do that as long as you fed that card into the various card reading devices the same way.
Of course, if you weren't the one actually feeding those cards to the machine, you would need to alert the computer operator to your deviant preference.
I worked with Data General, Honeywell and IBM card handling equipment. So there might be exceptions among Buroughs, Univac, NCR, CDC, and digital.
The corner cut was definitely observed by the equipment for checking card orientation. From a 1967 IBM Sorter Manual:

.Scott
.Scott
Homework Helper
The corner cut was definitely observed by the equipment for checking card orientation.
But it was still up to the operator to make sure that the cards were correctly oriented.
In fact, if this CC feature was used, the correct orientation could be any of the four card positions (face up or down, 9 or 12 edge forward).
I was using the 083 card sorter. I remember that extra loose brush for sensing the corner cut, but it was never something we used.
One trick is resurrecting a damaged card would be to feed it into a keypunch machine up-side-down and reproduce it onto another up-side-down card.

sysprog
symbolipoint
Homework Helper
Gold Member
The symbol shapes should be found in textbooks about programming. One can also find some of this information online:

https://www.programiz.com/article/flowchart-programminghttps://en.wikipedia.org/wiki/Flowchart
One thing I notice in some of the online references and pages is that no reference is found about the hexagonal flat shape for loops that I was taught. I'm still looking....

https://www.smartdraw.com/flowchart/flowchart-symbols.htm

But it was still up to the operator to make sure that the cards were correctly oriented.
Yeah, but it was up to the machine to reject the input if it was wrongly oriented. The purpose of the cut was to ensure that the orientation could be detected, not primarily by the operator, for whom the pre-printing on the card would suffice, but for the machine. If you failed to observe the rule, which usually for an input deck was 9-edge in face down, the machine would stop.
In fact, if this CC feature was used, the correct orientation could be any of the four card positions (face up or down, 9 or 12 edge forward).
That's true, but it's not consistent with your prior post, in which you said:
The card readers did not look for that cut.
Later, you acknowledged that they did look for it:
I was using the 083 card sorter. I remember that extra loose brush for sensing the corner cut, but it was never something we used.
Your not using it is obviously different from the reader machine not looking for it.
One trick is resurrecting a damaged card would be to feed it into a keypunch machine up-side-down and reproduce it onto another up-side-down card.
You could wire the plug-board on a card duplicating machine to allow that, but how would you get, say, an IBM model 29 keypunch machine to do that? It not only doesn't detect which corner is cut, but also as far as I know, it has no capability to read anything on a card, except if you wrap the card around the program drum to be used as a program card, and in that case it could only heed the codes specific to that keypunch machine; not duplicate the card.

The plug-boards on a reader, sorter, or duplicator could be wired to ensure the correct orientation for the intended purpose, and/or the intended action for each of the four possible orientations (left or right; face-up or face-down).

The default configuration for an IBM card reader in the '70s was such that you would load your deck into the hopper 9-edge in, face down, press the end of file button to make sure that the system didn't treat your deck as part of its predecessor, then press start. If any of your cards was mis-oriented, you'd get a machine check and the reader would stop. The orientation was detected by the position of the cut corner.

Last edited:
symbolipoint said:
One thing I notice in some of the online references and pages is that no reference is found about the hexagonal flat shape for loops that I was taught. I'm still looking....
It's for a 'preparation' operation or sequence -- if you google 'flowchart preparation box', you'll find many references.

symbolipoint
Homework Helper
Gold Member
It's for a 'preparation' operation or sequence -- if you google 'flowchart preparation box', you'll find many references.
I found only one reference in my search online through search engines. That one I later reported did show something like I expected: the hexagonal lengthened shape, one of the first things taught upon being introduced to FOR loop. I did not look much further after finding that one particular online reference, but I know it was in at least one old textbook.

I think there were numerous examples of forced excessive documentation. Not only was it not read, but in the maintenance phase, the burden of maintaining the documentation proved to be overwhelming.

But coming back to this thread, how much flowchart detail is enough? I say one page. A one page flow chart will be read and understood. More than that and the probability of reading/understanding drops rapidly. You can make a one page flowchart for a simple for loop or for putting a man on the moon. Simply adjust the level of detail.
Isn't your one page constraint arbitrary? Aren't some processes more complicated than others? Why should a description of something extremely complicated have to be confined to a same-size descriptor space as the description of something that is not nearly as complicated?

In flowcharting, we use an off-page element to show where the diagram departs to another page.

We should limit how much complexity we describe per page, but the utility of flowcharting depends on its accurately representing the process it describes, at the level of detail that reflects the intricacies of the process in a manner anticipated by the flowchart creator to be appropriate for the purposes of the person reading the flowchart.

It's obvious that a US road atlas shouldn't be one page instead of a book, nor should a state roadmap require as much space as a US road atlas; confine a world map to poster size if you want to, but a limousine driver's Chicago street guide rightly requires many pages.

I think that if you really think that no flowchart should require more than one page, then you probably also think that flowcharts are mainly useless.

Last edited:
I found only one reference in my search online through search engines. That one I later reported did show something like I expected: the hexagonal lengthened shape, one of the first things taught upon being introduced to FOR loop. I did not look much further after finding that one particular online reference, but I know it was in at least one old textbook.
You can find it at any of these (search 'preparation' in your browser when it's displaying the page):
https://www.rff.com/flowchart_shapes.php
https://www.smartdraw.com/flowchart/flowchart-symbols.htm
https://www.gliffy.com/blog/understanding-flowchart-symbols
https://www4.uwsp.edu/geo/faculty/gmartin/geog476/lecture/flowchart_symbols.html
https://en.wikipedia.org/wiki/Flowchart

symbolipoint
Homework Helper
Gold Member
That "smartdraw" was the one I showed in my post #31 after I said, "still looking...". That much satisfied me for the time.

That "smartdraw" was the one I showed in my post #31 after I said, "still looking...". That much satisfied me for the time.
Is the difference between the preparation box and the more common rectangular process box reasonably clear to you at present? [In a (not perfectly accurate) nutshell: preparation box is for 'fixed-overhead prerequisite' necessary to do prior to getting useful work done; rectangular process box is for elements and/or composites of the useful work.]

symbolipoint
Homework Helper
Gold Member
Is the difference between the preparation box and the more common rectangular process box reasonably clear to you at present? [In a (not perfectly accurate) nutshell: preparation box is for 'fixed-overhead prerequisite' necessary to do prior to getting useful work done; rectangular process box is for elements and/or composites of the useful work.]
No; not really too clear.

The hexagonal box is specifically the one I know to show the start of a loop, whether of FOR, or WHILE, or DO. The precise condition or range of numbers is shown inside this hexagonal box. Other instructions are then shown inside other symbolic figures. Often the programmer or student would put algebraic and arithmetic steps or other kinds of instructions inside a rectangle, depending what kind or how much detail is inside the loop.

sysprog
First to all, thank for the resource info and comments. More that I was anticipating to be honest, but very informative.

From post #1:
A question you should ask yourself is"why draw a flow chart?"
As @.Scott pointed out, flow charts were used before programming languages came along. Many textbooks for programming languages don't even bother with flow charts, but use pseudocode instead. Here's a wikipedia article on pseudocode, with examples in several styles: https://en.wikipedia.org/wiki/Pseudocode
I have read about psudocode and seen it in quite a few text book, honestly I am more a visual person in terms of learning. And when thinking of how to approch a coding issue I find it easier to draw a flowchart out and go from there. Overtime I suppose I will go the other way, but for now as coding is farily new to me, I find the approach easier.

sysprog
anorlunda
Staff Emeritus
Isn't your one page constraint arbitrary? Aren't some processes more complicated than others? Why should a description of something extremely complicated have to be confined to a same-size descriptor space as the description of something that is not nearly as complicated?
It's human. One page flowchart is like the 10 minute attention span for spoken monologues.

Earlier I mentioned putting a man on the moon. You could have countless pages of flowcharts for that. Nobody would read them.

One page flowcharts lead to decomposition as an analysis strategy. Each box in the first flowchart leads to a full page flowchart of its own, and each of those to more detailed, and so on. It treats the complex topic as a hierarchy, rather than a linear sequential machine.

Klystron, symbolipoint, jedishrfu and 1 other person
It's human. One page flowchart is like the 10 minute attention span for spoken monologues.

Earlier I mentioned putting a man on the moon. You could have countless pages of flowcharts for that. Nobody would read them.

One page flowcharts lead to decomposition as an analysis strategy. Each box in the first flowchart leads to a full page flowchart of its own, and each of those to more detailed, and so on. It treats the complex topic as a hierarchy, rather than a linear sequential machine.
That seems reasonable to me.

jedishrfu
jedishrfu
Mentor
Folks really hated big multi-page flowcharts with little connectors to send you elsewhere.

The preference was if it had to be big then make it into a wallchart.

Top-down programming encouraged this kind of one page flowcharting too.

Many early FORTRAN or COBOL programs weren't necessarily very large (well FORTRAN anyway) as programmers got smart and created tons of reusable library code that you could call. This in turn made the flowcharts arguably smaller since each call became a small box with the subroutine name listed.

And then we did away with flowcharts when structured programming (SP) took over, then OO replaced SP and then automated commenting assists of Eclipse etal... and now the current obfuscation style of coding sans comments... where we are smart enough to know what the other programmer did.

Last edited:
sysprog and Taylor_1989
symbolipoint
Homework Helper
Gold Member
honestly I am more a visual person in terms of learning. And when thinking of how to approch a coding issue I find it easier to draw a flowchart out and go from there. Overtime I suppose I will go the other way, but for now as coding is farily new to me, I find the approach easier.
The use of a flowchart is meant to appeal to that "visual" way of thinking. One builds his flowchart and can then also fill-in as many or all the steps in it, even to the extent of putting in code lines ; and then translating this into a sequence of code becomes very easy. The flowchart serves as a map of where the program (in that portion which the flowchart represents) is going. This helps you think as you develop this part of the program.

Klystron, jedishrfu, sysprog and 1 other person
anorlunda
Staff Emeritus
The most learning and deep understanding of algorithms that I ever got was from reading the pseudo code in Donald Knuth's famous books. For example, a Shell Sort in 2/3 of one page. A flowchart of that would have been harder to understand.

Klystron, QuantumQuest, Taylor_1989 and 2 others
The most learning and deep understanding of algorithms that I ever got was from reading the pseudo code in Donald Knuth's famous books. For example, a Shell Sort in 2/3 of one page. A flowchart of that would have been harder to understand.
Always great to see yet another affirmation of that Computer Science Archon, Professor Donald Knuth.

Klystron, QuantumQuest and jedishrfu
No; not really too clear.

The hexagonal box is specifically the one I know to show the start of a loop, whether of FOR, or WHILE, or DO. The precise condition or range of numbers is shown inside this hexagonal box. Other instructions are then shown inside other symbolic figures. Often the programmer or student would put algebraic and arithmetic steps or other kinds of instructions inside a rectangle, depending what kind or how much detail is inside the loop.
It seems to me that you've got it more clearly than you're advertising, and I find that to be A-OK; whence I say to thee, inquiritor, go thou forward.

The most learning and deep understanding of algorithms that I ever got was from reading the pseudo code in Donald Knuth's famous books. For example, a Shell Sort in 2/3 of one page. A flowchart of that would have been harder to understand.
May I ask what books? Would these books be good for someone who is new to programing?