Roadmap for RESCU Textbook / Future Topics

[wtbarnes]

We should start coming up with a clearer/ more organized view of what the textbook (or whatever you want to call it) should look like. I've laid out something very preliminary in the README for the RESCU/textbook repo, but maybe we should have a working copy in the brainstorm repo too. I don't know how best to divide up the units/modules. I've started just by dividing them up roughly by physical example and then using a specific class of problem (gravitation/central force, projectile motion, collisions etc.) to emphasize different scientific computing topics. What does everyone think about this?

Below is the README from the other repo for the lazy:

rescu_textbook

Lesson plans for pedagogical approaches to scientific computing.

Best to provide at least one chapter on introductory programming practice.

After that, can either organize by mathematical topic (ODE, data analysis, matrices/linear algebra) or organize by physical example-this may be more pedagogical, but less organized in some ways.

Ch. 0-Introduction

Introduction to Python/Programming

• variables
• arithmetic
• boolean logic-and,or
• conditional statements-if,elif,else
• iteration-for and while loops
• functions and reusable code; usefulness of functions; classes if theres time
• good programming practice
• much of this is best taught by example
• can provide some Project-Euler-type examples to show how these things are useful

Plotting-Introduction to Matplotlib

• how to handle figures/axes-setting figure options
• good plotting practices
• using colors, labels, legends
• plotting in higher dimensions-contour plots, surface plots if there's time
• scaling variables
• saving figures versus printing to screen

Using Numpy and SciPy

• vectors, arrays, matrices
• emphasize linspace,arange,etc.

LaTeX and Markdown

• using IPython notebook effectively
• Markdown syntax
• LaTeX syntax-formatting equations, usefulness outside of IPython environment
• differences between Python, IPython notebook-cell evaluation versus standard scripting environment

Ch. 1-Solving Ordinary Differential Equations (ODEs) by Example

• briefly describe differential equations
• basic definition, simple solution methods
• avoid calculus-heavy explanations

Projectile Motion

• basic projectile motion as starting point
• move toward example with air resistance

Simple Harmonic Motion

• free pendulum
• damped and driven pendulum
• double pendulum

Gravitation and Radially Symmetric Forces

• two-body problem; could extend to three-body problem if there's time
• electrostatics

Other chapters could include root-finding methods, matrix inversion/decomposition, Monte-Carlo methods

All should be framed in a context that's easily accessible to high school students; try to always provide good physical motivation for introducing topics.

[wtbarnes]

One new idea to think about:

I've currently structured the textbook as Chapter 0 having more purely programming concepts, i.e. without application.

Thinking about this a bit more, this really goes against what we want to do. Instead, I think the better way to do this would be to introduce a new programming concept at each chapter (or section or whatever).

So for example,

• Chapter One: introducing conditionals and iteration through projectile motion
• Chapter Two: using functions with simple harmonic motion
• Chapter Three: classes and gravitation

As far as the structure for each chapter goes, we can introduce the programming concept and deal with Python intricacies (with simple examples), talk about the physics and then it is up to the students to put the two together.

Presumably this all under our guidance in a "programming lab" format.

[ajkluber]

This all looks very cool Will. In regards to your comment,

Thinking about this a bit more, this really goes against what we want to do. Instead, I think the better way to do this would be to introduce a new programming concept at each chapter (or section or whatever).

We haven't made our "learn by example" style that we are after very concrete yet, but I think you have put us on the right track. I might suggest that whenever we introduce a new programming concept we have a bare bones example that shows the basic syntax (or most common usage), then immediately apply the concept to the problem at hand. In any case, these questions are bound to become clearer as we progress.

[ajkluber]

As we discussed at lunch today it has been easier for us to think of cool problems than ways to teach programming concepts. May I suggest that we, following Will's example above, fill out our course skeleton with the programming concepts that we want to cover first. Then brainstorm about the best examples to portray each one.

We should be concrete about what we want them to ultimately take away from the course. It seems that getting to classes makes sense (as the most complex concept).

[wtbarnes]

Why don't we start a list of potential programming topics in the wiki. I think this will help as we develop each lesson plan.

Having some sort of standard skeleton for each module I think would be helpful. I agree that we need a more concrete idea of what the structure of each lesson should look like. Based on what you said @ajkluber this might look something like this:

---

Module Title

Introduction

What is the programming concept, describe it, why is it useful

Example Use Cases

Some very basic vanilla use cases, no application yet

Application to Physical Problem--Tutorial

Apply to the physical problem at hand, show why this helps us solve the problem, how it is applied

Application to Physical Problem--Exercise

Now the student applies the concept to the problem, perhaps an extension or harder version of what was shown in the tutorial. This could be the "lab" section

---

Maybe the first two parts can be combined into one. I suspect the course time will be heavily weighted toward the latter two so maybe we should break those up, particularly the Tutorial section.

I think we should really nail down a good lesson skeleton before anyone starts working on specific modules.

[ajkluber]

Dan and I met today and did a little brainstorming about programming concepts. I added it to, Timeline and Skeleton. There is also a section for physical problems / applications.

I guess what @wtbarnes calls "chapters" I called "tiers", but same thing really. In any case, I want to shy away from using "advanced" because it carries a lot of psychological baggage (it is scary). I added your previous comments to Lab Session Skeleton.

[wtbarnes]

Thanks for doing this @ajkluber. I think the Timeline and Skeleton is very helpful, particularly the "tiered" system. I think this is basically what we've been getting at for a few months, but it is good to have it in writing.

[ajkluber]

Added today's minute and some ideas Will and I talked about to the course skeleton.

Specifically Will and I talked about splitting the 16 week semester into chunks (for example ~5 chunks of three weeks) where within a chunk we keep working on the same physical problem, developing the sophistication of the code as we introduce new concepts. This way we don't jump from topic to topic every week and can get more in depth. Ostensibly we will have shorter chunks in the beginning for the easier stuff and longer chunks at the end for harder stuff. This brings us closer to a concrete timeline for the course.

Random thoughts from today (some of which has been touched on before):

• We figured that class 0 will be introduction ("why python?", "why this course?", etc.) and setup (installing anaconda, etc.).
• Maybe we the final goal of the course is sharing the code they have been developing on Github?
• The class that introduces outside packages should probably use numpy + scipy.