Mathematicalengineering (or engineering mathematics) is a branch of applied mathematics, concerning mathematical methods and techniques that are typically used in engineering and industry. Along with fields like engineering physics and engineering geology, both of which may belong in the wider category engineering science, engineering mathematics is an interdisciplinary subject motivated by engineers' needs both for practical, theoretical and other considerations outside their specialization, and to deal with constraints to be effective in their work.
Historically, engineering mathematics consisted mostly of applied analysis, most notably: differential equations; real and complex analysis (including vector and tensor analysis); approximation theory (broadly construed, to include asymptotic, variational, and perturbative methods, representations, numerical analysis); Fourier analysis; potential theory; as well as linear algebra and applied probability, outside of analysis. These areas of mathematics were intimately tied to the development of Newtonian physics, and the mathematical physics of that period. This history also left a legacy: until the early 20th century subjects such as classical mechanics were often taught in applied mathematics departments at American universities, and fluid mechanics may still be taught in (applied) mathematics as well as engineering departments.[1]
The success of modern numerical computer methods and software has led to the emergence of computational mathematics, computational science, and computational engineering (the last two are sometimes lumped together and abbreviated as CS&E), which occasionally use high-performance computing for the simulation of phenomena and the solution of problems in the sciences and engineering. These are often considered interdisciplinary fields, but are also of interest to engineering mathematics.[2]
EGR 1010 is an applied mathematics course taught by the College of Engineering and Computer Science faculty, consisting of lecture, lab, and recitation. All topics are driven by engineering applications taken directly from core engineering courses. The lectures are motivated by hands-on laboratory exercises including a thorough integration with Matlab.
There are 8 hands-on lab assignments that supplement the course material. Additionally, there are 4 self guided Matlab supplemental assignments that illustrate a more application-based approach to coding. The labs below are written as if students are in the lab with equipment. The virtual labs mimic what is done in-person and can be used in lieu of the hands-on labs. As such, while the lab requirements remain unchanged between both the hands-on and virtual labs, the procedures may differ. The included videos below outline the step-by-step process for the virtual labs.
This post first appeared at Grading For Growth earlier this month. There is a second part as well which I'll repost here later, or you can just click and read it now. I've added some new thoughts to the end of this post just for
rtalbert.org readers!
With summer officially underway, I'm going to be writing for the next two weeks about the grading system I had in place for the semester that just ended, in my Linear Algebra and Differential Equations classes. David wrote a couple of posts on his experiences (part 1, part 2) and mine will be along the same lines.
The first installation today is about the "theory" of the class -- all the background information about the class and my philosophy of teaching it that led to the grading process that I used. Next week, I'll focus on the "practice" -- how it was received by students, what worked and did not work in real-life practice, and what I'll do again and do differently next time.
The class that I taught was MTH 302: Linear Algebra and Differential Equations. This is a four-credit course primarily intended for students in engineering that combines topics from these two gigantic areas of mathematics. I taught two sections, each two hours long, back-to-back on Tuesdays and Thursdays. Enrollment hovered around 30 students in each section, and all the students were second- or third-year engineering majors (with the exception of one lone Accounting major who was working on a math minor).
You'll find versions of this course at many universities that offer engineering degrees, and it's clear that many profs who teach it don't quite know what to make of it. Linear Algebra and Differential Equations, as separate subjects, are significant enough to merit two required courses each, but in MTH 302 we put them both into a single class. There are two ways to handle this kind of compression. One is to build the course around a small, reasonable core of content and learning outcomes that necessarily leaves out some interesting math, and then set up structures to help students learn those things deeply. The other way, which is seemingly far more common, is to leave nothing out, and just Cover All The Things at an enhanced speed and diminished depth, trusting that the "good students" will somehow keep up.
The Cover All The Things approach makes the course tend toward procedural rather than conceptual knowledge (because conceptual knowledge is slow cooking), so the course ends up as a hyper-accelerated flythrough of a cookbook, with a lot of the best recipes missing. The experience for students and instructors alike becomes impoverished, uninspiring, and aimless.
Those three adjectives also describe many of my students' past experiences with math courses, including MTH 302's prerequisites of Calculus 1, 2, and 3. Every student in MTH 302 has completed these; a good portion of my students "completed" them as though escaping through a fire. Don't get me wrong: MTH 302 students are high-achieving and highly capable. But many were simply Calculus survivors, with a survivor mentality about Calculus and other forms of math.
And not to get ahead of myself, but when you've had experiences akin to Covering All the Things in a traditionally-graded system, the survivor mentality goes into overdrive. If you have to learn how to compute things correctly by hand, assessed by one-and-done tests with no feedback loops, every day in class is about survival.
I'd taught Linear Algebra before, and Differential Equations before, but never this weird mashup. I certainly wanted to avoid the negative experiences with the class I'd seen elsewhere. My first order of business, then, was to make the class less weird, by answering the question: What is this class about? I don't mean, What topics does it cover or What does the catalog say. Instead I mean the same thing as when we ask someone what a book or a movie is about.
As I looked at the individual "halves" of the course -- linear algebra, and differential equations -- and how those two subjects interact, I decided that MTH 302 is about modeling systems that undergo change, and seeing what we can learn about those systems from the models. This felt right: Both topics grow out of the need to model real-life systems like ecosystems and spring-mass systems, that change and evolve over time and whose behavior we want to predict.
On a more immediately practical level, I had factors to incorporate into the design of the class at this point. First, as I said, I'd never taught this particular class before, so I wasn't too interested in any radically different approach from what I had used in the past elsewhere. Second, and related, this was a service course for the Engineering school, and I didn't (and still don't) have a great sense of their tolerance level for "far out" pedagogical practices. Third, the students in the course, being engineering majors, were maxed out with a demanding set of courses in their discipline, and I was very hesitant to create a wild new course structure that demanded more cognitive load than necessary.
In particular, I decided at the outset that I would not use ungrading in the course. Since that term is so ambiguous, what I mean is that I would not do what David did in his geometry course or which I did in my Winter 2022 abstract algebra course, where student work got no grades but just feedback, and we collaboratively decided on course grades at the end. I don't think it would have been absolutely wrong to do this with MTH 302; but relative to my newness with this course and what I understood about the constraints on students, it didn't seem like the right call. However: Come back next week for more thoughts on this.
What you'd see if you walked into a typical class would be 6-8 groups of 3-4 students doing heads-down work on a problem that guides them toward understanding of some important learning objective of the course. Sometimes students went to the board to work; other times just working quietly, but very often not quietly, with their friends. My role was to be everywhere all at once, going from group to group to answer questions, prod people along with questions, and check to make sure everyone was OK and progressing.
I've always felt that there were three more-or-less independent axes along which success in a course should be determined: mastery of basic skills, mastery of applying those basic skills to new situations, and what you might call "engagement" or "being in the course". An "A" student is one who can demonstrate consistent excellence along all three axes. A "C" student is one who is "just good enough" on the first two axes and makes a reasonable effort on the third. That 3D axis model seemed to fit particularly well in MTH 302, where there were a lot of basic skills that are important to master, as well as a large helping of applications to master as well.
With the context, philosophy, and assessments all laid out, we can now talk about the grading system. All the criteria for grading different forms of work is spelled out in this document called Standards for Student Work in MTH 302. To summarize:
3a8082e126