We have discussed the fundamentals of programming as consisting of data & actions (often on data) and organizing the actions via sequence, selection, repetition and modularization. This practice/learning activity will revisit those ideas in more detail focussing on Boolean expressions and data which are used for making decisions and recording the state of the program, e.g., ready to stop. (Some simple selection or repetition may be used but is not expected to add much complexity or confusion.) The learning activity is described after the Process Reminders below.
Keep the "pair programming" process in mind as you work. One person types and the other person watches and corrects, questions, etc. After a bit (at most 30 minutes) you change roles.
This activity is for you to learn, so it is not graded. The learning will be inferred in the PARR (Programming Activity and Reflection Report) document you (eventually) submit and in one of the in-term exams. Remember to add to your notes for the PARR.
If you have questions about the assignment send me an e-mail or drop by my office. If you have a question while working on the assignment do the same. Keep in mind that when you encounter something you can't figure out you can/should think, explore, seek answers on google, etc. but, do not spend more than 15-30 minutes trying to overcome a particular error or problem.
The syllabus noted a couple ways you might earn extra credit. I am adding another.
One is to share some aspect(s) of programming or Snap! you think others might not have experienced. You should annotate your program using the program notes (File icon | Program notes) and/or comments blocks (see p.68 of the Snap! Reference Manual. The annotation should describe or explain the learning/insight(s) you want to share.
To receive extra credit for such an annotated program on this activity you will also need to submit a copy of your algorithms. Either create a PDF of a document or include the text in your submission message.
The alternative method to work for extra credit is that the partnership could suggest additions to our how to do it page. You might suggest a revision to clarify (or finish) something that is there already or an entirely new topic. Please indicate how/why you think the would be helpful. Be sure you fully and clearly describe what you are talking about.
The third method to receive a bit of extra credit is to submit the "Create your own problems ..." that you created and solved. Include all three problems and a pseudo-code algorithm of each solution.
Submitting something for either kind of extra credit is as simple as sending an e-mail message. The message should:
The goal here is to create Boolean expressions that can be used to answer questions. The questions can be nearly anything but will have only a yes/no (true/false) answer. For example, Is the child old (or tall) enough? Is the person over- (or under-) weight? Is the person's height (or blood pressure or sugar level or ...) "normal"? Am I getting a B or better in the course? Should repetition be continued? Should repetition be stopped? You can probably think of many other examples. Remember, we are working on producing expressions (code) that will answer such questions.
The questions will typically involve an
repeat statement. They will almost always make use of some program data. It will be important that you think in terms of the data being used and/or the current state of the program.
Eventually, you will have to worry about the actions associated with the questions but for now we will focus on producing code to answer the questions (and reporting the answers).
I suggest you use the following script in the Stage to control the program action.
Then for each problem there will a matching script that gets executed by some sprite. The code for that would replace the "say" block in the following script and perhaps use a different number in the "when I receive __" block.
Relational operators are used to compare two values. The comparison will produce a value of true or false. The items below ask you to create scripts that will indicate an answer to a question—yes or no, true or false. The scripts should show the question (briefly stated) and it's answer under the current data conditions.
Produce a script for the following algorithm. The essence of the algorithm is that we are answering a question by performing the appropriate actions on data. The resulting answer is true or false (yes or no).
ask "Hours worked?" and wait set hours to answer ask "Pay rate?" and wait set rate to answer say join ([Account for overtime? ::] <hours > 40>) for 2 secs
Report whether the temperature entered by the user indicates it is freezing? (Use whichever temperature scale you prefer.) A possible algorithm is provided below.
ask "Temperature?" and wait say join ([Freezing? ::] <answer < 32>) for 2 secs
Report whether the sprite's location is above the x-axis.
Test the mouse's location. Indicate whether the mouse is below the x-axis. Note: You will probably want to use the code similar to that in one of the two scripts to the right to accomplish this task. Your actions for this item would go in the first
if and other items in the following if blocks as needed. Alternatively, you could do similarly with the
if ... else blocks. Again, we would use this whenever we have actions that need to recognize both an item number and the
mouse down? reporter. An even better alternative may well be the third option show—a
when block with an
and operator. Just place your code below that block. (I feel sorta stupid for not finding this sooner :-)
As above but you choose mouse or sprite and now it might be on the x-axis. Think about how you will test this code?
As above, but with the x coordinate instead of the y coordinate.
Have one sprite ask and answer the question of whether it is closer to a second sprite than to the mouse (when the mouse is clicked).
Determine whether the number entered by the user is even. An even number is divisible by 2 or equivalently an even number
mod 2 will result in 0.
One definition of obese is that your BMI (body mass index) is greater than 30. The formula for calculating the BMI is
weight · 703 bmi = -------------- height2
where weight is in pounds and height is in inches. (BTW, a BMI value of 18.5-25 is considered "normal" with 25-30 overweight.)
Do the same as number 1 above but have your "answer" reflect the question "Overtime not appropriate?"
Determine whether the number entered by the user is odd. An odd number is not divisible by 2 or equivalently an odd number
mod 2 will not be 0 or will be less than 0 or greater than 0.
Quadrant I is where both x- & y-coordinates are greater than 0. If needed, look up information about quadrants on the coordinate plane.
Using the dice rolling sprites from last time, have both sprites roll their dice and report whether the roll was a natural (7 or 11). Just report "Natural?" followed by true or false depending on the value of the roll.
Using the dice rolling sprites from last time, have both sprite roll their dice and report whether the roll was a crap-out (2, 3, or 12). Again, just report "Craps?" followed by true or false depending on the value of the roll.
The normal range for height of American males is 69.5 inches ± 3 inches and for American females 64 ± 2.5 inches. Using whichever test you wish, get input from the user for height and indicate whether that person is of normal height.
Using the information from the above item, get input from the user for height and gender, then indicate whether that person is of normal height.
It really is not good coding style to use a forever block, particularly if you do not include some mechanism for stopping all scripts. One way to avoid this is to use a
repeat until <done> block. Snap allows us to create a reporter block that will return true or false (or some other value).
In this case we will want to make a new block and call it done. When you do so, I recommend it be for all sprites; be in the sensing palette; and have the name "done".
When you click "OK" you are allowed to define it. Just click on the sensing palette and drag & drop the
key [space] pressed block into the data spot on the "report" block in the definition. It should look like the image to the right when completed.
You could define your done flag using some different "reporter" or testing some variable for a particular value.