Simulating Car Dynamics with a Computer Program: Part IV
The next pieces of state information are the three components of the car's velocity. When the car is going in any direction on the course, we can ask "how fast is it going in the x direction, ignoring its motion in the y and z directions?" Similarly, we want to know how fast it is going in the y direction, ignoring the x and z directions, and so on. Decomposing an object's velocity into separate components along the principal coordinate directions is necessary for computation. The technique was originated by the French mathematician Descartes, and Newton found that the motion in each direction can be analysed independently of the motions in the other directions at right angles to the first direction.
The velocity of our race car is retrieved via the following expressions:
To end this month's article, we show how velocity is computed. Suppose we retrieve the position of the car at simulated time t1 and save it in some variables, as follows:
We have used define to create some new variables that now have the values of the car's positions at two times. To calculate the average velocity of the car between the two times and store it in some more variables, we evaluate the following expressions:
The nesting of expressions is one level deeper than we have seen heretofore, but these expressions can be easily analysed. Since they all have the same form, it suffices to explain just one of them. First of all, the define operation works as before, just creating the variable vx and assigning it the value of the following expression. This expression is
(/ (- x2 x1) (- t2 t1))
In normal mathematical notation, this expression would read and in most computer languages, it would look like this:
(x2 - x1) / (t2 - t1)
We can immediately see this is the velocity in the x direction: a change in position divided by the corresponding change in time. The Scheme version of this expression looks a little strange, but there is a good reason for it: consistency. Scheme requires that all operations, including everyday mathematical ones, appear in the first position in a parenthesised expression, immediately after the left parenthesis. Although consistency makes mathematical expressions look strange, the payback is simplicity: all expressions have the same form. If Scheme had one notation for mathematical expressions and another notation for non-mathematical expressions, like most computer languages, it would be more complicated. Incidentally, Scheme's notation is called Polish notation. Perhaps you have been exposed to Hewlett-Packard calculators, which use reverse Polish, in which the operator always appears in the last position. Same idea, and advantages, as Scheme, only reversed.
So, to analyse the expression completely, it is a division expression
(/ ...)
whose two arguments are nested subtraction expressions
(- ...) (- ...)
The whole expression has the form
(/ (- ...) (- ...))
which, when the variables are filled in, is
(/ (- x2 x1) (- t2 t1))
After a little practice, Scheme's style for mathematics becomes second nature and the advantages of consistent notation pay off in the long run.
Finally, we should like to store the velocity values in our data structure. We do so as follows:
The set operations change the values in the data structure named car-161. The exclamation point at the end of the names of these operations doesn't do anything special. It's just a Scheme idiom for operations that change data structures.