set.seed(12345)
<- rnorm(10)
y <- matrix(rnorm(20), 2)
x <- lm(y ~ x)
linmod ## Error in model.frame.default(formula = y ~ x, drop.unused.levels = TRUE): variable lengths differ (found for 'x')
Frequently asked questions
Course Workflow: Homework and Labs
RStudio Git Workflow
Working with Git in RStudio involves several key steps:
- Ensure you are on the
main
branch. Pull in remote changes by clicking the down arrow . - Create a new branch by clicking the branch icon .
- Work on your documents and save frequently.
- Stage your changes by checking the appropriate boxes.
- Commit your changes by clicking Commit.
- Repeat steps 3-5 as needed.
- Push to GitHub by clicking the up arrow .
- Open a pull request (PR) on GitHub.
- Use the dropdown menu to return to
main
to avoid potential issues.
Command Line Git Workflow
If you prefer using the command line, follow these steps:
- Pull remote changes (optional but recommended):
git pull
- Create a new branch:
git branch -b <name-of-branch>
- Work on your documents and save frequently.
- Stage your changes:
- For specific documents:
git add <name-of-document1>
- For all changed documents:
git add .
- For specific documents:
- Commit your changes with a meaningful message:
git commit -m "Descriptive commit message"
- Repeat steps 3-5 as needed.
- Push to GitHub:
git push
(follow any suggested command variations) - Open a pull request on GitHub.
- Switch back to
main
:git checkout main
Homework Regrade Procedure
- Deductions must exceed 3 points and be related to content (not penalties).
- Errors can be corrected to potentially raise the grade to 7/10.
- Revisions and review requests must be submitted within one week of the initial review.
Regrade process:
- Locate the local branch for the specific homework assignment.
- Check the “Pull Requests” tab in your GitHub repository if you can’t recall the branch name.
- Make necessary corrections to the files.
- Commit and push changes, ensuring the PDF is re-rendered if needed.
- Find the original PR for the assignment on GitHub.
- Add a concise, clear comment to the TA describing your changes.
- Click the recycling (🔁) button under “Reviewers” to request a review.
Common Git and Workflow Issues
master/main
“master” has some pretty painful connotations. So as part of an effort to remove racist names from code, the default branch is now “main” on new versions of GitHub. But old versions (like the UBC version) still have “master”. Below, I’ll use “main”, but if you see “master” on what you’re doing, that’s the one to use.
Start from main
Branches should be created from the main
branch, not the one you used for the last assignment.
git checkout main
This switches to main
. Then pull and start the new assignment following the workflow above. (In Rstudio, use the dropdown menu.)
You forgot to work on a new branch
Ugh, you did some labs before realizing you forgot to create a new branch. Don’t stress. There are some things below to try. But if you’re confused ASK. We’ve had practice with this, and soon you will too!
(1) If you started from main
and haven’t made any commits (but you SAVED!!):
git branch -b <new-branch-name>
This keeps everything you have and puts you on a new branch. No problem. Commit and proceed as usual.
(2) If you are on main
and made some commits:
git branch <new-branch-name>
git log
The first line makes a new branch with all the stuff you’ve done. Then we look at the log. Locate the most recent commit before you started working. It’s a long string like ac2a8365ce0fa220c11e658c98212020fa2ba7d1
. Then,
git reset ac2a8 --hard
This rolls main
back to that commit. You don’t need the whole string, just the first few characters. Finally
git checkout <new-branch-name>
and continue working.
(3) If you started work on <some-old-branch>
for work you already submitted: This one is harder, and I would suggest getting in touch with the TAs. Here’s the procedure.
git commit -am "uhoh, I need to be on a different branch"
git branch <new-branch-name>
Commit your work with a dumb message, then create a new branch. It’s got all your stuff.
git log
Locate the most recent commit before you started working. It’s a long string like ac2a8365ce0fa220c11e658c98212020fa2ba7d1
. Then,
git rebase --onto main ac2a8 <new-branch-name>
git checkout <new-branch-name>
This makes the new branch look like main
but without the differences from main
that are on ac2a8
and WITH all the work you did after ac2a8
. It’s pretty cool. And should work. Finally, we switch to our new branch.
Improving Your R Programming Skills
Learning Approach
Learning to code is an active, immersive process. Simply reading books or watching videos is insufficient. To truly learn R:
- Complete tutorials multiple times
- Explore textbook code thoroughly
- Question the rationale behind function choices
- Experiment with different coding approaches
- Break down and understand each line of code
Recommended Learning Resources
Debugging Code
General Debugging Workflow
When your code doesn’t run:
If the code runs but doesn’t produce expected results, see the code quality section.
Read the Error Message
- Error messages provide crucial debugging hints
- Parsing them can be challenging but is a valuable skill
Example:
Notice the error about variable lengths and matrix dimensions.
Consult Documentation
- Use function-specific help (e.g.,
?matrix
)
- Use function-specific help (e.g.,
Search Online
- Copy error messages into search engines
- Remove specific, identifying information
Seek Peer Help
- Use class Slack channels
- Prepare a minimal working example (MWE)
Instructor/TA Consultation
- Be prepared to show your code
- Provide a reproducible example
When seeking help, always be ready to share your code or MWE.
Note: If the error cannot be reproduced, it is unlikely that anyone can help you effectively.
Crafting Minimal Working Examples (MWEs)
An MWE is a compact code snippet that:
- Reproduces an error on any machine
- Isolates the specific problem
- Minimizes external dependencies
Benefits of creating MWEs:
- Often helps you solve the problem independently
- Reveals the root cause of issues
- Makes it easier for others to help you
MWE Tips
- Set random seeds for reproducibility
- Use minimal, generic data
- Include only essential code
Preparing an MWE is a valuable debugging skill. By stripping your problem down to its bare essence, you often uncover the root issue. For instance, the previous debugging example was an MWE: it used a fixed seed, ensured data reproducibility, and focused on a specific error.
For further guidance, consult:
Writing High-Quality Code
This is covered in much greater detail in the lectures. Here are key principles for writing clean, efficient R code:
Use Script Files
- Save and source scripts
- Avoid console-only work
- Treat R as a scripting language, not a calculator
Avoid Code Repetition
- Never copy and paste code
- Define constants at the script’s beginning
- Create reusable functions
Function Design
- Functions are easily testable
- Verify inputs and outputs
- Catch potential errors through comprehensive testing
Error Types
- Syntax errors (detectable by R)
- Missing parentheses
- Incorrect arguments
- Logical errors (require thorough testing)
- Require manual verification of results
- Syntax errors (detectable by R)
Avoid Magic Numbers
- Always define constants
- Make numerical values meaningful and clear
Use Meaningful Names
Bad example:
data("ChickWeight") <- lm(weight ~ Time + Chick + Diet, data = ChickWeight) out
Good example:
data("ChickWeight") <- lm(weight ~ Time + Chick + Diet, data = ChickWeight) chick_weight_model
Comment Strategically
- Explain code that isn’t immediately clear
- Focus on the “why”, not just the “what”
Example of helpful commenting:
# Calculate weighted average of chick weights, squared and adjusted <- with( chick_weight_summary ChickWeight,by(weight, Chick, function(x) (x^2 + 23) / length(x)) )
Remember: Clear, readable code is as much about communication as it is about functionality.