Flow Chart For a 'for' Loop In Python

[symbolipoint]

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...

This page shows a different shape indicating a loop:
https://www.smartdraw.com/flowchart/flowchart-symbols.htm

 

[sysprog]

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.

 

[sysprog]

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]

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.

 

[sysprog]

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.

 

[sysprog]

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]

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

 

[sysprog]

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]

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.

 

[Taylor_1989]

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 textbook, 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.

 

[anorlunda]

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.

 

[sysprog]

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]

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.

 

[symbolipoint]

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.

 

[jedishrfu]

There are alternatives to flow charting that were popular for a spell. One was the Nassi-Shneiderman diagram:

https://en.wikipedia.org/wiki/Nassi–Shneiderman_diagram
NS preserved the true/false breakdown of a condition statement as two columns but the columns got too thin to be useful.

Others are listed at the end of this flowchart article on wikipedia:

https://en.wikipedia.org/wiki/Flowchart

 

[anorlunda]

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.

 

[sysprog]

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.

 

[sysprog]

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

Some walls have looked empty to me without these charts:

http://biochemical-pathways.com/#/map/1http://biochemical-pathways.com/#/map/2
I'm not really a biochem guy, but we all have a compelling interest in it , right?

 

[sysprog]

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.

 

[Taylor_1989]

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?

 

[jedishrfu]

The Art of Computer Programming by Donald Knuth

https://en.m.wikipedia.org/wiki/The_Art_of_Computer_Programming
These are classics in the field though not everyone owns a copy. They are akin to an encyclopedia of algorithms and as such take some skill and effort to understand not necessarily a good fit for a newbie programmer.

I considered getting a copy but when i saw it coming out in fascicles decided to wait until it was finished. I am still waiting since 1982, it isn't finished and I imagine granddaughter will just have to wait too.

 

[JayZ0198]

I don't use flowcharts that much but that is because I've finished learning how to use python and don't need them anymore. But, back when I was still learning python they were persistent on flowcharts being used as it was easier to understand the code. The way I learned it was that parallelograms are a input or output, rectangles are a processes, ellipses are start or end, and diamonds are a decision or check whether a condition is met. I wouldn't stress about flowcharts because when you finish learning it no one uses it seriously.

 

[sysprog]

The Art of Computer Programming by Donald Knuth

https://en.m.wikipedia.org/wiki/The_Art_of_Computer_Programming
These are classics in the field though not everyone owns a copy. They akin to an encyclopedia of algorithms and as such take some skill and effort to understand not necessarily a good fit for a newbie programmer.

I considered getting a copy but when i saw it coming out in fascicles decided to wait until it was finished. I am still waiting since 1982, it isn't finished and I imagine granddaughter will just have to wait too.

Professor Donald Knuth is a man the praises regarding whom I cannot sing highly enough. Maybe his pipe organ (yes, everyone, he explains why it has to be a real pipe organ) can sing that high, but I can't. May all that is good be presented to that great man. And oh yeah when you use $\TeX$ you're using that man's code. He wrote it.

 

[rcgldr]

At one of my old jobs, we bought a program (AllClear) that converted psuedocode into a flowchart, but after a couple of months, it became clear that the pseudocode was easier to follow than the flowchart, and the flowcharts were abandoned.

As for Python using a list for a counter, it's not clear with 3.0 and later versions what happens in range(). In Python 2.7, xrange() was used to iterate a counter, not produce a list, unlike range(), but Python 3.0 deprecated xrange(), and I'm not sure if Python doesn't optimize range() into xrange() depending on how it's used.

 

[jedishrfu]

My understanding is that range() is dynamic in this respect and similar to xrange() returning an iterator that generates the next number in sequence whereas the old range() generated a list, taking up a fair amount of memory, that was then iterated over.

https://www.pythoncentral.io/pythons-range-function-explained/
So range() became deprecated and xrange() became the new range() in python3.

 

[sysprog]

At one of my old jobs, we bought a program that converted psuedocode into a flowchart, but after a couple of months, it became clear that the pseudocode was easier to follow than the flowchart, and the flowcharts were abandoned.

As for Python using a list for a counter, it's not clear with 3.0 and later versions what happens in range(). In Python 2.7, xrange() was used to iterate a counter, not produce a list, unlike range(), but Python 3.0 deprecated xrange(), and I'm not sure if Python doesn't optimize range() into xrange() depending on how it's used.

Yes, that's true -- it was a problem regarding memory pre-allocation versus ad hoc dynamic allocation -- now it's dynamic-only ...

 

[sysprog]

My understanding is that range() is dynamic in this respect and similar to xrange() returning an iterator that generates the next number in sequence whereas the old range() generated a list, taking up a fair amount of memory, that was then iterated over.

https://www.pythoncentral.io/pythons-range-function-explained/
So range() became deprecated and xrange() became the new range() in python3.

I agree with what Sifu Jedi said.

 

[sysprog]

I made a glaring error in a post in response to @.Scott.

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.

This is wrong. It completely ignores the read station on the Model 29. If, for example, you made an error on a single column of a card, say column 51, and didn't notice until you had typed all the way through column 71, you could feed the next blank card, the hit the reg (register) key, which would advance the prior card to the read station, and position the new card at the punch station. Then you could hit and hold the dup key to duplicate the first 50 characters, then type the corrected character for column 51. and then hit and hold the dup key for the rest of the remaining non-incorrect characters. Then when you hit the release key, you could discard the errant card, and be on your merry way. Sorry about the mis-statement earlier.

 

[jedishrfu]

I am reminded of a story at GE years ago where a top keypunch operator noted for her speed was brought into test the latest and greatest new keypunch machine guaranteed to handle the fastest typist until they met Sue. She typed so fast there were noticeable pauses on the machine while it struggled to keep up. She liked the machine but sadly no it’s wasn't fast enough for the best operators. The sales guy was quite flummoxed over it but GE bought a few anyway.

 

[sysprog]

Professor Knuth (Donald Knuth, of TAoCP and $\TeX$ fame) used to regularly outspeed the fastest electric typewriters. He loved the first IBM Selectric he encountered, in part because although he could outspeed it too, its buffering capability allowed it to catch up when he'd pause.