I am learning to use flow charts for school. How can I improve this flowchart?
I have been playing with micro-controllers as a hobby for about 3 years now and I have yet to make a flow chart. For my EE101 class I have to make a flow chart to solve a problem."Build a flow chart using counters to add the odd numbers between 1 and n. Where n is a positive integer inputted." I think I am close however I see two problems. The red box needs some type of function to determine if the number is even or odd. my arrows go every where the examples shown in class seemed to flow smoothly. I would appreciate any help or suggestions. thank you
EE101_AMF_HW_3-19_flow chart.pdf
Do you create flow charts for most of your projects? If so do you make them before or after you write the code?
EE101_AMF_HW_3-19_flow chart.pdf
Do you create flow charts for most of your projects? If so do you make them before or after you write the code?
Comments
I've been programming for many years and I've rarely created a flow chart unless I was required to for a class or work project. I have found it much more useful to create a "pseudo-code" program where the control structures like IF, FOR, REPEAT, etc. are written out in a sort of functional style using indenting and the rest of the program is given as prose descriptions of what's to be accomplished at that point in the program. When I've had to create flow charts, I would make them from the "pseudo-code".
There are a few rules that I was taught with flowcharts by a professor several years ago that have stuck with me.
1) Only one START and one STOP allowed
2) No entrapments ; a flowchart should not cross lines and/or paint itself in a corner allowing for escapement.
3) A functional block should only have one input and one output
4) A decision block should only have one input and two outputs
Following that, rule #1 in your flow chart is broken, but can be easily be fixed by combining the "OUTPUT ANS".
Rule #3 is broken and two of the decision blocks could be combined into one decision block. Since BOTH outputs from the decision blocks are going to the same locations and since the decision that needs to be made is the same at both decision block locations, this redundancy can be reduced.
These rules aren't written in stone by any means, but it does make for a more streamline flow architecture if they are followed.
I typically test bit0 of the value to do this. If bit0 is 1 the value is odd, otherwise even. In Spin:
Like others I use a mix of flow-charts (usually for processes, not the whole program) and pseudo-code.
BTW... 'CNT' is a known entity in the Propeller (system counter) so you may not want to use this in your flowcharts unless that is the actual intent. In your chart I think you're actually meaning "count." The idea behind flowcharts is clarity -- this is a case where an abbreviation can lead to confusion.
a+b = c
But they are usually coded
c= a+b
Also, the Flowchart is done first, to get a good "picture" of how the logic is going to flow.
Pseudocode is done next, after you know how the logic is going to flow, when you want to figure out how the program is going to be arranged.
Experts can appear to skip steps, but they do not; they simply have enough experience and do it in their heads (more or less).
Non-experts do skip steps, and have disasterous results, particularly when they are working in groups. We see this at "professional" organizations that chronicaly miss schedules and deadlines, and have never-ending bug lists.
The rule of thumb is it takes longer to skip steps than it takes to simply take the time and do it "right". Don't skip the flow chart unless you have already deomonstrated you are an expert, by having a (previous) project that showed you no longer need them.
Odd and even?? well in binary integer if the lsbit is set its odd - to test you have to use whatever your language allows; I guess anding with one is quickest...
While I'm at it, I do miss the old dot matrix fanfold continuous paper - Ive printed out assembler maybe 25 - 30ft long. Unfold a big chunk on the floor - hands and knees - ah those were the days
Dave
( I cant quite figure your flowchart soooo....)
answer=0
count=0
input n
n>0? YES>
>count=count+1
>-is count odd? YES>---->answer = answer+count
>count=n? YES---->--Print "sum off odd number from 1 to ";n;" is ";answer
END
NO | NO NO
| | | |
|
<
<
<
<
ERROR!
Ever so sorry but what I typed in the box DID NOT appear as I typed it - its seems that multiple spaces to align stuff is not allowed and not having flowchart software
Gosh I think thats it but its a lot easier with pen and paper (It looks ORRIBLE done like this!!!)
Dave
Sweet machine!
They still make 'em too.
EE101_AMF_new flow chart.pdf
For this assignment I was not allowed to use code. I was only allowed to us algebraic functions.
Any suggestions are appreciated. thanks!
P.S. I agree that c=a+b looks better and is more logical than a+b=c. The examples given in class were in a+b=c format and my teach is picky about having things his way.
a + c = d
or
d = a + c
Are statements of fact. i.e. that the stuff on the left side of the "=" is the same value as the stuff on the right hand side.
When used as an assignment statement in computer programming they have a different meaning. So
d = a + c
means "add a and c and make d equal to the resulting value.
This is why languages often have different types of equals operators. In C for example "=" means assignment whereas "==" means compare for equality, as used in "if" statements.
In most languages things like " a + c = d" have no meaning as assignments and are an error.
As for flow charts, I have not seen any one using them for decades, professionally or otherwise. In the mid 1970's we were taught flowcharting whilst learning to program in BASIC. Given that BASIC is a crude and unstructured language flow charts helped a bit.
For my first real work, programming in assembler we used to write out what we wanted to do in pseudo code, in our case something that looked like Algol. Then proceeded to write that in assembler language. Then hand assembled that into hex for the loader. We had no assembler for that processor at the time.
In that position pseudo code was essential to keep you ideas straight and the code in a good structure. I discovered that pseudo code was a lot better way to do this than flowcharts.
P.S. I take back my statement about not seeing flow charts for decades. Just remembered that last year I had to implement a serial line protocol that was specified with flow charts. One for the master end and one for the slave. The protocol was not complicated but those flow charts did not help to understand it and turned out to be wrong anyway! Besides in that case the flow charts indicate protocol behavior and not code flow. State transition diagrams would have been better.