These are example algorithms that you can run in order to see what your algorithm should do. They were written by the person that wrote the homework problem and hence they pretty clearly demonstrate what they had in mind.
On a few points the problem statement is not clear, such as on #3 regarding how big to make the shapes or where within the window to place them. Running the Compiled Example will make these points clear - especially when you consider that this problem is not autograded. I will be grading them and I am looking for you to do something reasonable - so don't worry if your circles are not exactly the same diameter as the example. Do something that is reasonable after seeing what the Compiled Example does.
People are making mistakes by not carefully reading the problem. For instance, if the problem states that you are to round your answer either up or down to the nearest whole number, your submission will fail to pass the autograder if you don't do this.
There is no margin for error on this. If the problem states to name your algorithm FRED.rap, then it must be named FRED.rap. Not MY_FRED.rap or jsmith_FRED.rap or anything else. If it is not named FRED.rap, the autograder will not find it, it will not get graded, and you will receive a zero on it. Period.
If you have a flowchart called fred.rap, there will probably be several files in your directory such as fred.rap.backup0 and fred.rap.backup1 and so on. These are back up files that are created automatically by Raptor. Every semester several people submit one of these files instead of the current file (fred.rap in this case). It's easier to do than you might think. Be sure you submit the file you intend to submit.
You will be making three separate submissions for this homework assignment using the "Submit Files" link on the course homepage. Select HW#2 for each of them.
Don't say, "None," if you received any assistance at all. The documentation statement should be for the problem that the file being submitted is for. In other words, when you submit HW2-1.rap, only provide documentation for help received on problem #1. Document help received on problem #2 when you submit HW2-2.rap. If you re-submit a file and have nothing to add to the documentation statement, say, "See above".
For help received from me (as in ME and only ME - this does NOT apply to help received from another CS-110 instructor) you may simply say something like, "Received EI from Mr. Bahn." Feel free to be more explicit, but that is sufficient.
The first two problems will be autograded. You have the opportunity to run your algorithms against the exact same test cases that the autograder will use. As a result, you will know at the time you turn your algorithms in whether it will receive credit or not (and remember, autograded problems are all-or-nothing).
To run your algorithms against the server, simply have the file open in Raptor, have it named correctly, and be on the network. Then bring down the "Run" menu from the menu bar and select "Test against server." The autograder will run your algorithm and tell you whether you passed or failed each of the test cases it used. These test cases are not the same as the example test cases included in the homework handout, but if you don't pass those, then you are unlikely to pass the autograder.
The Help Policy is quite lenient but it is unforgiving on one point - do NOT copy another cadet's work! Do not even look at another cadet's algorithm until you have submitted your own. This also includes having one cadet looking at their own flowchart and then telling you what to do or, conversely, you looking at your flowchart and telling someone else what to do.
When you are helping someone else, don't tell or show them exactly what to do - this doesn't help them learn how to do it and can get both of you in a lot of trouble. Look at what they have done and then ask them questions designed to help them find the problem themselves, such as, "Okay, but what is your algorithm going to output if the person's GPA, MPA, and PEA are all exactly 3.0?"
For a number of reasons, Raptor records information with each and every single symbol in a flowchart. This information includes the name of the person and computer on which the symbol was created as well as every time it is copied from one flowchart to another. Even if the file is transferred via e-mail or thumb drive, this source information comes along for the ride - it is part of the symbol and can't be separated from it.
For the most part, this information was intended to be used used to track statistics regarding how long it takes people, on average, to work the problems. But it doesn't take much imagination to see other uses for this information as well - and the scripts are in place and run automatically on the submitted files. Bottom line, if you copy a single symbol from another cadets file, we won't have to spot it - the script will report it to us and we will be unable to ignore it even if we wanted to.
No matter how tempting, they do not do what you want and cannot be made to do what you want.
Look in the Raptor Help (press F1 while in Raptor) and look at the Colors section. Figure out which numbers are associated with the colors listed in the problem statement. Then think about all the time we have spent talking about generating random integers between two limits.
Input blocks do one thing and one thing only - they get input from the USER and store that input in a variable. That's it. Nothing more. They do not result in output to the command console. They do not affect the flow of the algorithm. They do not alter a graph window in any way.
Output blocks do one thing and one thing only - they place output to the Command Console. That's it. Nothing more. They do not get input from the User. They do not change the values stored in any variables. They do not affect the flow of the algorithm. They do not alter a graph window in any way.
Assignment blocks do one thing and one thing only - they evaluate an expression and store the result in a variable. That's it. Nothing more. They do not get input from the User. They do not result in output to the command console. They do not alter a graph window in any way.
Call blocks turn control of the flowchart over to another flowchart temporarily. That's it. Nothing more. That other flowchart may do lots of different things - it may open a graph window, it may draw a circle, it may wait for a mouse button to be pressed, it may play a sound file. Very shortly, you will use it to call subcharts that you have developed.
Selection blocks evaluate an expression and generates a Yes or No answer and directs flow down one of two paths accordingly. Both paths eventually come back together further down the flowchart. That's it. Nothing more.
Loop blocks are almost identical to selection blocks. They evaluate an expression and generate a Yes or No answer and directs flow down one of two paths accordingly. The only difference is that one of those paths eventually loops back to a point above the decision box so that the same question can be asked repeatedly. That's it. Nothing more.
Here's the Raptor Program that plays the High Low game we have been talking about.
Remember from Grade School how you used to do division - 16 divided by 3 was equal to 5 with a remainder of 1.
What do you know about a number if it's remainder when divided by another number is zero. For example, since 35 divided by 7 has a remainder of zero, what do you know about 35 as far as its relationship to 7 is concerned? What do you know about the relationship between all even numbers and the number 2?
Look in the Raptor Help for any math operators that deal with the remainder when one number is divided by another.