184_notes:comp_process [Projects & Practices in Physics]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Coding: Group Process for Computational Projects ======
Our in-class coding projects are unique, and require different group strategies than an analytical or design project. In this page of notes, we'll lay out some strategies for success when coding with your group.
===== Pseudocode =====
Making a plan is just as important for coding as it is for hand-written calculations. Without one, it's easy to get lost and turned around. One of the best ways to plan for coding is using pseudocode.

Pseudocode is a simple way to plan out the process or steps the computer should follow. When writing pseudocode, don't worry about using exactly the right names or calculations. Instead, focus on an overview and write out in words what the computer should do. For example, the following is pseudocode for numerically computing an integral:
<code>
define bounds
sum = 0
while x is in bounds:
    evaluate function at x, multiply by dx
    add to sum
    increment x
</code>
Talk through what each step should do as a team, and rework your pseudocode until it seems correct. Once you have some solid pseudocode written out and agreed on as a team, it's easy to convert it to code and test your program. Trying to make changes to a full code program is much more complicated than rearranging some pseudocode. 
===== Commenting =====
We'll often provide you with a minimally working program to build on top of. On these days, it's very important to figure out exactly what the provided code is doing, and where your team needs to edit the program. Read through the code as a group, and after each line add a comment that says in words what that line is doing. In python, anything on a line after an octothorpe (#) is considered a comment, and the computer will ignore it. These comments will likely be very similar to what pseudocode for the program would look like.

<code>
x = 0           # initialize x
bound = 10      # define bounds
sum = 0         # initialize sum
dx = 1          # determine size of little piece
while x < bound:        # while x is in bounds
    val = (5*x) * dx    # evaluate function at x, multiply by dx
    sum += val          # add to sum
    x += dx             # increment x
</code>
===== Predictions and Evaluations =====

Before you start coding, it is important to define goals, predict what the code's output should look like, and draw any necessary representations. These steps will guide your team through the project, and prepare you to evaluate your solution for accuracy. 

If the code is intended to create a visual, think through what that visual will look like and draw it out. It often helps to run the code once without editing it, to see what "scene" your team is provided with. Figure out what the changes you need to make will add to the scene, and draw out what that should look like. 

When your team has completed the program, assess how closely it matches your predictions. Are there errors in your prediction? In the coded model? Think through ways that the coded model could more closely reflect reality, and any improvements that your team can add.
===== Logistics =====
An easy way to get very lost as a group is having each person looking at a separate computer screen with their own version of the code. Instead, pick a single person to type the code with input from all other group members. Choosing a coder with less programming experience will make sure that your entire group stays together. If you are a CS/CMSE/Computer Engineering major, you probably should not be coding. 

In class, one of the best ways to keep everybody on the same page is starting a zoom meeting, having each team member log in on their own device, and having the coder share their screen with the program up. Then you'll each be able to see what's going on without huddling around one small screen.