CS 1150 PEEE   Fundamentals—Boolean Data

Overview

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.

Process Reminders

Pair Programming

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.

Grading

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 or difficulties

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.

Extra Credit

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:

• be sent to east@cs.uni.edu
• be CCd or sent to each partner
• have a subject of PEEE extra
• have, in the body of the message, an indication of which of the three kinds of extra credit your are seeking along with the information for the extra credit if you are not submitting a program.
• have your program attached if you are submitting an example of programming learning and your algorithms

Learning Activity

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

The Questions

Using relational operators

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.

1. pay needs to include overtime?

   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
   

2. freezing?

   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
   

3. y coordinate (of sprite) is positive?

   Report whether the sprite's location is above the x-axis.

4. y coordinate (of mouse) is negative?

   

   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 :-)

5. y coordinate (of sprite or mouse) is non-negative?

   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?

6. x coordinate (of sprite or mouse) is positive?

   As above, but with the x coordinate instead of the y coordinate.

7. x coordinate (of sprite or mouse) is negative?
8. sprite (or mouse location) is on the x-axis?
9. sprite (or mouse location) is on the y-axis?
10. closer to sprite than to mouse?

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

11. number is even?

    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.

12. am I obese?

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

13. create (and solve) your own simple problem using relational operators

Adding logical operators

1. pay need not include overtime?

   Do the same as number 1 above but have your "answer" reflect the question "Overtime not appropriate?"

2. number is odd?

   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.

3. x coordinate (of sprite or mouse) is non-negative?
4. sprite (or mouse location) is in quadrant I

   Quadrant I is where both x- & y-coordinates are greater than 0. If needed, look up information about quadrants on the coordinate plane.

5. sprite (or mouse location) is in quadrant II?
6. sprite (or mouse location) is in quadrant III?
7. sprite (or mouse location) is in quadrant IV?
8. craps roll an initial winner?

   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.

9. craps roll an initial loser?

   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.

10. height is "normal"?

    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.

11. height is "normal"? (version 2)

    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.

12. create (and solve) your own simple problem using both relational and logical operators

Producing your own reporters

1. Done flag

   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.

2. create a Boolean reporter of your own for some task you think would be useful.