Teaching physics effectively is difficult. Teaching physics and programming (effectively) at the same time is more difficult. This early lesson is a critical moment. I’ve had three shots at it under varying circumstances. Here is what happened, this time:
In a short class period, this flow of reasoning unfolded in a dialog with teacher and students: These scripts make a sprite move for 14 seconds. We are trying to simulate the 14-second motion of Lego robots for which we collected time and position data in class:
The leftmost script is a choppy sprite move of 20 pixels every two seconds. The rightmost is a relatively smooth move of 1 pixel every 0.1 seconds. Students are able to see the connection between the arguments of the repeat, wait, and change-x-by blocks. The wait blocks are necessary to make sure the sprite motion lasts a time equivalent to the Lego robot motion (for us that is 14 seconds).
After analyzing lab data, students answer a series of questions that leads to algorithms for calculating velocity and displacement (change in position). I remind them they already know this by asking: You are in a car that travels 50 miles/hour for 2 hours; how far do you go? They are hardwired for that calculation. They get it. The algorithm is: multiply velocity and time to determine displacement.
Here is the second day: Back in Snap! I tried to lead them to accomplish the same smooth animation, but working with more sophistication. Having established that motion is position changing as time changes, I assert that our script should control time and position, We make a clock (pretty easy for them) and I point out that change-x-by and change-y-by are the two most fundamental position controls and we must commit to using only them. The clock forces the making of a variable called sim time and its smallest time increment called delta-t.
We run the simulation with delta-t equal to 1 (second), at first. When the simulation runs we can watch the choppy movement of the sprite and the clock tick off whole seconds. Since we now know that smaller time increments improve the look of the simulation, making it more “smooth”. Reducing delta-t to 0.1 seconds makes a smooth simulation.
At this point the change-x-by block argument is still a white space that the user must define.
Here is where I feel that I do not have the luxury of time (or the bright idea) to lead students to make a variable called velocity and multiply velocity by delta-t in an operator block placed as the argument of the change-x-by block (See figure).
This idea does connect to the class time that supports this activity, but students need help to remember that displacement is equal to velocity multiplied by time. I had to show most students how to get the right expression into the change-x-by block.. And at this point I chose to instruct the students to use a repeat until block instead of a repeat block so that we can use a time-based decision using a Boolean expression.
I think the Boolean is easy enough to understand, but I was rushing to finish to get a working script. And here it is:
The students have no reason to think that using variables like this is better than the original method used to simulate the motion. This does nothing better and it requires more blocks. My assertion that it is a better technique sounds hollow. I realize that we must work this way because in the next unit velocity will change when we simulate accelerating objects. It will be impossible for the user to input the argument for change-x-by because that argument will change. Maybe I should tell them this. It would not be worse than my hollow assertion.