I learned a lot this week, no surprise there. The first half of the week focuses on designing worlds via the big-bang function in Racket. Think of the big-bang as a sort of event loop (but it’s much different in implementation due to Racket being a functional language). So as big-bang runs, you need to tell it what to do by writing different functions. But well before that, you need to address your data! The most important thing is always the data definition, and with compound data even moreso.
Compound data is data that is “naturally” linked together. Think x,y coordinates, speed and position, or name and age. If you want to track more than one piece of data, then you’ll need compound data. It’s fairly simple to initialize via define-struct your-struct . Luckily this course has a language reference because I keep forgetting where parens should go.
OK next I learned to design worlds with this compound data, the lecture topic was a cow that walked back and forth across a screen and changed directions when it hit a wall or the user pressed the space bar. Again, we have these recipes to guide our design. The most difficult part for me is writing the check-expect which is the test you write before even coding the function to compare inputs with expected outputs. Usually a good check-expect will write your function for you. To give an example if I write (check-expect (double 2) (* 2 2)) I mean to say that when I run double on 2 I expect to get out 2*2 or 4. Writing 2*2 instead of 4 actually illuminates what the function should do, which helps you and any future user.
I also worked through all the practice problems this week before attempting the “Design Quiz” I’ll tell you nothing gave me more grief than rolling this little bastard back + forth across the screen.
The first part of the problems was just to slide back and forth, which was relatively simple because we had worked through a similar problem in class. The second part was to make it rotate while spinning. This was harder as I had to modify my data structures to account for rotation, luckily the rotate function can accept negative numbers, so it can change directions of rotation.
Finally we had to adjust rotational speed based on radius to actually “roll” it back and forth. Man this was a nightmare, the formula was given to change degrees rotation to distance required to travel, but I only had a velocity component. After some time I realized that a velocity dx scaled by rotational speed (2pi*r/360) would give the required change in angle dr. Anyway that guy rolls! These recipes make the design process more straightforward, and if you force yourself to stick with them you won’t get sidetracked or forget edge cases.
Top comments (0)