## Computing in Mathematics: Build your Own Calculator

For the past few Fridays, I have been teaching my first ever lessonsto a class of Norwegian students, and I wanted to write about the experience here.

This class was a class of 30 or so Norwegian students in Mathematics 1T, which covers the the topics of precalculus and differential calculus. The students in this course had just finished studying functions, and function notation.

I asked students about their previous programming experience—many students had done some programming in scratch, one had done some work in HTML, and none had any experience in Python.

Here is initial throught thought about how to structure a series of lessons for incorporating programming into math class. Students are already quite comfortable with calculators like Desmos and Geogebra, and readily see their utility in mathematics. Why not introduce Python as a sort of “build your own calculator,” emphasizing their ability to program their own functions that will be useful for future work?

Ideally, I could imagine that students in an Algebra 2 or Precalc class build a file of functions that would be useful for their own work in mathematics—functions to find the x-intercept of a line, the roots of a quadratic, or even the slope of a fuction at a point. Once students learn to master a procedure, they then develop that procedure into a function in Python, and later, are free to use that function on future assignments.

For this type of introduction, I decided to start students off in the Repl.it web programming environment. If you have internet connectivity in your classroom, Repl.it is a great environment to work with because there’s nothing to install or configure, and yet you get the exact same Python interface you would get from installing IDLE or Anaconda (without having to wait half an hour for Anaconda to download).

The other choice I made was to start by working directly with the Python interpreter, rather than writing actual Python scripts. This requires students to enter commands where into the interpreter one at a time. After most commands, the interpreter gives you some feedback. So if you enter “3+7”, you’ll see 10 appear below the prompt. If you try to enter a command that requires multiple lines, like a function definition, the interpreter prompt switches to an ellipses “…” allowing you to enter each line of of the command. And if your line happens to include mismatching parentheses, you’ll be able to tell because Python won’t return to a normal prompt until the braces are matched. Finally, if you have any syntax errors in the line you wrote, you’ll get immediate feedback in the form of an error message right under the line.

I think there are a number of advantages to first working with the Python interpreter. In normal Python programming, where you are running a script, your errors appear in a separate window, and I’ve found it very hard for students to connect and interpret these error messages as having important feedback about their code. If you want to check the value of a variable, you simply need to type the variable name on its own line, and Python will print the contents of that variable. Working in the interpreter also gives you an opportunity to predict the output of each line of code before running it, which is also a valuable activity when first learning to program. And finally, for the exercise of building your own calculator, working in the interpreter feels much more like how a calculator actually operates.

## Lesson Plan

Every student brings up the a Python environment using repl.it on their laptop.

We start by entering some simple addition problems into the interpreter—”4+6″, and I ask them if they can figure out and check the other mathematical operations—subtraction, multiplication and division, and they quickly find “-“,”*” and ,”/”.

I then show them the “%” operator, and ask them to spend some time exploring what it does. I start by giving them some examples.

`5%3 --> 2`

`6%3 –> 0`

`10%3 --> 1`

`I ask the students to spend some time exploring this operation. What are the possible outputs for this operation? What exactly is this operator doing?`

Students make some interesting discoveries—the output is at most 1 less than the second number in the operator. When we get more systematic, exploring 1%3, 2%3, 3%3, etc, they see the output follow a cyclic patten. Eventually, students are able to predict the pattern from a few examples, and then with a bit more nudging, and some cross cultural discussion about the differences in division notation between Norway and the US (did you know that the US division sign functions as the minus sign in Norwegian? And long division on Norway looks completely different from how I was taught), they recognize the modulus operator that gives you the integer remainer from division.

At this point, I give them a cheat sheet of various python commands I pasted together from the internet and ask them to spend a few minutes exploring some of the examples in the cheat sheat. When we report back, students have discovered all sorts of neat things like

print(“Hello” * 2)

>”HelloHello”

### Defining functions

Since students had just studied function notion, and my ultimate aim was to help them build a library of useful functions for mathematics, I decided to introduce them to defining functions in Python.

Students see that function definitions in Python can look remarkably like mathematical function definitions. We start with a simple linear function.

def f(x):

return 2x+3

Python also makes it pretty easy to create piecewise functions, like this

def f(x):

if x >= 0:

return 2x+3

else:

return 3

Next, we talked about the difference between a variable and a parameter, and how in the code below, the x in the function is not the same as the variable x—this tends to be a very confusing concept for students who are just starting out with programming.

x = 3

def f(x):

if x >= 0:

return 2x+3

else:

return 3

This was pretty much the end of the first day of programming and 90 or so minutes of work. A week later, I came back with a Desmos activity I had created to help them test their ability to read code and understand basic Python operations. The first screen was a matching exercise where students matched 4 small 2 line programs with their output.

Then students took a crack at reading and predicting the output of a small program:

Thanks to the awesome computation layer, I was able to create a follow up screen that showed students what they wrote as the output and ask them to resolve any differences between their prediction and the output of the program.

Lastly, I created a simple slider for students to state how they felt about our work thus far:

Once we discussed their work on this Desmos activity, I wanted students to see how we can use Python to define functions that aren’t “mathematical” and so worked together to develop a function that would take an (x,y) pair as an input, and return the Quadrant that contains that point, I, II, III or IV.

We began this process by developing a small flow chart to help us think through the logic:

From this, I tried to do some interactive live coding where students would tell me what to write, and eventually, we put together a function that looked something like this.

def Quadrant(x,y):

if x < 0:

if y > 0:

return "I"

else:

return "IV"

else:

if y > 0:

return "II"

else:

return "III"

It was super helpful to have the flow diagram to go back to be able to show at various points in the coding how much of the function we had written. But as students were trying to follow along to write this program themselves, things went a bit off the rails. It was a bit of a jump to go writing code that had nested commands three levels deep, and I again found myself running around helping students make sense of all the various syntax errors they were being. Not good.

Sadly, class was just ending, so I had to leave with a lot of students feeling frustrated.

On the third day, I came back with another exercise to follow up on our work on the quadrant function. This time, I’d rewritten the code we discussed last time, adding a syntax error and a error in the algorithm, and asked students to spend the first bit of class debugging. This turned out be great. Students did a great job of finding the syntax error, and they were having productive discussions to try to figure out the bug in the program that was producing incorrect output. Many of them saw that debugging is way harder (and more interesting) than just finding syntax errors, and a few that finished early started to walk around the room to help out their peers.

Once we had a working Quadrant function, we started to create our own functions, lke this,

def f(x):

return x**2 + 4

`print(Quadrant(2,f(2))`

to see how our function nicely predicts points along an whole variety of functions. We really started to have fun when the teacher suggested looking at the sine function, which I imported, and we could quickly see how our function’s predictions perfectly matched the graph of sin(x) in Desmos.

### Reflection

By the end of the third session, some students were really beginning to enjoy programming and thinking through the execution of a program. A few were still finding it pretty frustrating and wondering why programming must be so hard. This is something I really want to work on in the future in my own teaching. Much more than my experience teaching physics, students who begin to program seem to quickly separate themselves into people who develop a quick love for it and people who think it’s not for them. Often, I think this is tied deeply to a student’s previous experience with programming and programming adjacent activities, like taking things apart, working with simple machines, etc, and I would love for a way to help students who think programming is not for them because they aren’t getting it as quickly as their peers to see that often, their peers have had much more previous experience that forms much of the basis of their seeming “intuition.”

I also think there’s a real need to develop many small formative assessments for students who are programming, and to center most of these activities and assessments around reading code and making small modifications to scaffolded code. Too often, I think we ask students to write code from scratch, and not only is this something that rarely happens in the real world of programming, it is deeply challenging for students to work on translating their ideas for a program into an algorithm and then master all the tiny syntactic details necessary to get a working program. There are lots of strategies to help with this, like writing pseudocode, running your program often to find errors, but I think for some students, this still isn’t enough, and a few minutes trying to find your error in the 20 lines of code you just wrote in one sitting is a nearly impossible task.

Finally, I wonder if these assignments are dreadfully boring. It turns out that the Norwegian math curriculum barely addresses the notion of Quadrants, and I’m not sure that students are excited to build a library of functions they could use as their own custom built calculator as I would be. Certainly there are contexts, like working with vectors, calculating cross products and unit normal vectors where this idea might really help students to see just how powerful a Python driven calculator could be, but if we really want students to see the power of programming as a tool to explore mathematical thinking, I think we need to keep working to find better topics to explore.

## Coding as conversations: Pair programming

Recently, I saw Aatish Bhatia share this excellent TEDxCalgary talk from Marie-Claire Shananhan and Pratim Sengupta about coding in public spaces.

My favorite quote from the video was, “Learning to code isn’t about acquiring a thing or a skill. It’s about participating in rich and meaningful conversations together.”

I’ve seen this quote in action in many ways this year, in conversation with colleagues at UiO and across the world, on twitter, via Skype and more. But I think the most powerful way in which I’ve seen coding as a conversation has been with two former advisees, H and Y, both of whom are now juniors in college studying computer science.

H and Y were extraordinary advisees, and somehow we ended up keeping in touch once they went to college, scheduling Skype/Google hangouts a few times every semester. Both of them have given me great insights into what college-level STEM courses are looking like these days and many ideas for how we can improve our teaching and student life at my school. We’ve talked about finding summer internships, ethics in computer science, cool class projects they’re working on and much more.<

Recently, I’ve been working to learn React and Firebase to build an app I’ve wanted to create—Physics Coach (blog post forthcoming). For a good part of the fall, I spent a lot of time reading books on React, watching videos, and honestly, not making a ton of progress. It doesn’t help that it seems like the React/Javascript/web development ecosystem is evolving at such a fast rate that notation seems to be changing on a monthly basis.

Earlier this fall, I had the the bright idea to reach out to H and Y for some advice and invite them take a look at some of the code I’d written. Thanks to Zoom and Visual Studio Code Live Share (ZOMG—VS Code is the most amazing code editor ever), it was super easy to set up a pair programming session.

After six or so pair programming sessions with H and Y, I’ve made tremendous progress in developing Physics Coach, and in my understanding of React and Javascript. I think I’ve also given them some good practice for coding interviews as they’ve answered some of my questions and helped to troubleshoot code. We always start our sessions with me setting out a small goal, like setting Firebase up to write the homework sessions into its database or incorporating Google’s awesome material-ui into a login dialog. In all of these sessions, I feel like I’m 10x more productive when pair programming then when I am working on my own—this comes from being forced to explain my thinking and voice the things I’m uncertain of, and having someone else who able to ask questions, share different perspectives and help me talk through the logic of a particular coding challenge.

I think H and Y would say these sessions have been equally valuable for their learning, but I’ll let them speak for themselves in the comments. I also am thinking about how I might be able to bring something like this to my computer science classes. Might it be useful to pull students into a pair programming session with the teacher from time to time? I could see many ways to make this work—from live coding sessions where the student is the driver and the teacher and student are working together to implement a program that is just beyond the student’s current understanding, to having the student as the co-pilot on a more challenging project where the teacher serves as the driver, giving the student an opportunity to see how larger software projects are developed. I also think pair programming sessions with the teacher might help students to understand the value of pair programming better—something I’ve found that beginning students tend to discount when they think the programming challenges are easy and they can solve them themselves.

In the meantime, I think pair programming can be a way to grow the computer science teachers community, especially the <a TeachersCoding movement that Evan Weinberg has written about that seeks to help teachers understand how code can be a powerful tool to help their teaching. So if you’re ever interested in doing a bit of programming, usually after 10 pm Central European Time, hit me up!

## Coding in math class: comparing programming and problem solving

As I’ve mentioned previously, most of the focus of my sabbatical in Norway is working with faculty at the University of Oslo to help prepare middle and high school teachers for a National curriculum revision in Norway that will require math teachers to incorporate programming into the math curriculum at all levels in grades 1-13. As part of that work, I’ve now gotten to visit a number of Norwegian schools and see some of the early efforts at incorporating programming into the maths curriculum.

Overall, I’m deeply impressed by what I’ve been seeing. The government of Norway is making a serious commitment to funding professional development for teachers, and the effort to bring about this change in the curriculum is strongly focused on giving students another tool to explore and think mathematics rather than just “preparing students for future careers.” The Norwegian teachers I’ve met are also very enthusiastic about the possibilities and opportunities to improve the Norwegian math curriculum to incorporate more problem solving and inquiry based learning.

I’ve also see that Norwegian classes and schools are quite varied. The Norwegian educational system is founded on national commitment to equitable school funding that would be unheard of in the States, it even goes so far as to provide additional funding for schools that have large populations of at-risk students, and as a result every school I’ve been visited is beautiful and fully stocked with all the furnishings, equipment and resources one could imagine needing to teach a great physics or math class. At the same time, I’ve sat in on math class ranging in size from 7 students to 39, and I’ve been thinking a lot lately about how you teach programming to students in such varied environments.

Here’s something I seen in my own teaching of computer science that I find to be particularly challenging—namely how to manage large classes when students are working individually or in small groups and each student/group is in need of assistance from the teacher. Teaching programming in a math class seems to exacerbate this, since students aren’t seeing programming every day, and students are likely to have a wide range of programming backgrounds—some are quite experienced and can often race through an assignment that a novice will struggle with. What often results is every student getting stuck on their own individual problem, and needing the attention of the teacher to help debug. The bugs students encounter, particularly when they are typing their own code from scratch, run the gamut, and I’ve found most beginning students are unable or very reluctant to interpret the error messages or do much troubleshooting on their own. So what happens is you as a teacher are faced with a 20 or so students, intermittently calling for help with problems that you have to diagnose and help solve on the spot, and while your attention is focused on one student or group, the other students who are waiting are steadily growing more frustrated.

I want to think for a moment about similar spaces and classes where this doesn’t happen. The first thing I think of is many of the math classes at my school that focus on Exeter-style problem solving. Here, students are working in groups of 3 or 4 every day on challenging problems that are often beyond their individual reach. It’s not uncommon for students to be working on problems at the whiteboard in these small groups for nearly the entire class, with the teacher just walking around and checking in on each group throughout the class. Students still get stuck here, but it’s rare to see moments where an entire group can’t make progress and is calling for the teacher to intervene.

I’m curious about this difference. I think it’s true that problem solving in math and programming often provide equal levels of challenge to students, but in my experience, students I’ve taught have a much better sense of WDYDWYDKWTD (What Do You Do When You Don’t Know What To Do) when they are problem solving math class as opposed to programming. I think there are lots of reasons for this, and I’m sure the fact that problem solving sits at the hear of our math curriculum, and teachers spend a lot of time helping students to develop these WDYDWYDKWTD skills, and it’s clear those skills don’t transfer to programming when you’re faced with some sort of seemingly indecipherable error message.

This makes me think that even if programming is an topic that is occasionally interwoven into a math class, it would be helpful to spend some time explicitly teaching students many of the skills that are helpful for debugging—running your program often, interpreting error messages, learning to add print statements and comment out blocks of code to localize bugs, and all the other things we teach in computer science classes that help students to become more comfortable with debugging their own code. Of course this takes time and practice—students often don’t pick up these habits until they’ve really struggled to get a program or two working, and I’m not sure how you fit all this into a math class that already has a lot of content to cover.

But my experiences thus far make me worried for the teacher of 30+ students in a math class who is trying to get their students to do some sort of programming activity that asks for students to work independently in class. What sort of structures or activities could a teacher put in place that don’t consume too much time but could help students be better at troubleshooting their own code?

## An example of computational thinking as a sense making tool in the mathematics curriculum: the locker problem

I need to write a much longer post detailing my work in Norway and all the things I’ve learned, but I first want to publish this very small example of some of of the things I’m working on.

Here’s a little bit of background. The Ministry of Education of Norway has decided to make programming part of the 1-13 mathematics curriculum for all students in Norway. This requirement will be part of an overhaul of the entire curriculum in all subjects launching in 2020.

In addition, the Norwegian government has allocated a significant amount of funding to support training and professional development for teachers. Since most math teachers have very little previous exposure to programming, this is going to be a very big undertaking.

I’m working with some faculty at the Center for Computing in Science Education at the University of Oslo to help develop training and lessons for teachers in Norway. At the moment, we are developing training for a cohort of year 8-10 math teachers in the Oslo Kommune, which will consist of a single day workshop followed by 3 half day workshops later this year.

Our goal is to train these teachers in the fundamentals of python programming, and also to help them find ways opportunities for where programming and computational thinking can extend and enhance mathematics education. I’ve been re-reading Paper’s Mindstorms lately, and again am taken with Papert’s description of how the computer can create an environment where students are free to explore and test their mathematical ideas. There is another blog post I need to write about re-reading Papert—it’s amazing to me how relevant this book is to educational technology and computing 20 years after he wrote it.

All of this has put me on a quest to find interesting problems in mathematics that might be fun to explore with computing, and this is where I want to share the example of the locker problem.

I can clearly remember when I saw this problem in my 8th grade Algebera class. Newly (over)confident that I was proficient in solving any equation involving x, I was completely thrown by this problem because there didn’t seem to be any equation I could write. My 30 year old memory is hazy beyond that, but I mostly just remember wanting to know the answer, and not really having any tools to explore it. Were I teaching this problem today, I’d love to send my students off with whiteboards, and have them make sketches trying to find patterns for the first few students.

There’s so much you can do to think through this problem with pen and paper, but now, I also got to thinking it is a great problem to also explore with a bit of computing.

I’ve created this Juypter Notebook for my first draft of an activity that explores the Locker problem with computing. Here’s a version that is viewable on the web.

In creating this activity, I decided to take a scaffolded code approach. I wanted to provide students with some code that they could use for their own explorations, and assume they have only a very basic understanding of python loops and arrays. I created a Locker class that held the number of the locker, the current status of the locker (open or closed), the number of times the status has been changed, and the list of students who “touched” the locker, along with functions to “flip” and print the status of the locker.

From this, students can create an array of lockers, and then go about flipping various lockers to explore the problem. One goal of the assignment is to get them to see how they could simulate the problem and then look for patterns to generalize.

From here, I’m hoping students can do a bit of noticing and wondering about the patterns they see in this set of lockers, or possibly see what the patterns look like when they do the same action on 100 lockers.

I’ve never taught middle school before, but, my thought is that if students were comfortable with the basics of programming and the Juypter environment, they could walk through this notebook and use it to test and expand the initial work they did to think about the problem on paper or a whiteboard.

At this point, I’d love some feedback. Does being able to quickly simulate all 100 or 200 lockers give students more insight into the problem? Does it allow students more room to explore their own ideas, perhaps seeing what happens if you skip a student in this process? There definitely seem like plenty of ways for students who are comfortable with programming to extend this code—perhaps printing a list of all of the open lockers, or a function that will print the number of times a locker was touched.

## Exploring the Hydrogen Spectrum with Glowscript

As part of my sabbatical work at the Center for Computing in Science Education, I’ve learned a lot about the Norwegian Science and Math Curriculum, and gotten to meet some teachers who are doing very great work at bringing programming and computational thinking into their classes. In the next few posts, I want to share out some examples of what I’ve been working on.

One topic that isn’t a part of the high school physics curriculum I’ve taught is the Bohr model and in particular, the formula for calculating spectral lines

I must admit I’ve always found this formula a bit hard to build an intuition around. You’re calculating the inverse of a wavelength, and it’s dependent on the difference of the inverse of the squares of two integers. It was easy enough for me to realize that if you transition over a greater number of quantum states, the energy of the released photon must increase, resulting in a higher frequency, smaller wavelength photon, but that was never obvious to me from working with this equation as a student.

A teacher I met designed an activity to give students more practice with thinking about this formula by asking them to write a simple python program to calculate the wavelength of the emitted photon for a given transition. Once they had this program, it was much easier for students to think conceptually about questions designed to push their understanding. For instance, you could ask them to calculate the wavelength of the transition from n = 101 to n=1 to the transition from n =100 to n=1 and let them see that these wavelengths are nearly identical, and then come to the idea of ionization energy.

This discussion got me thinking that a glowscript program might add a bit more to this work since you could also display the spectral line that is produced for a particular transition. After doing some searching for some code to convert wavelengths to RGB values, I was able to put together this program:

And here is what the program produces. The top black bar is the reference spectrum of the Balmer series. If I were giving this to students, I would remove the lines 14 and 15 that calculate the wavelength of a particular transition, and ask students to implement the function to calculate lambda. Then I would ask them to try various transitions to see if they could produce the Balmer spectrum.

I’m not sure this is the deepest application of computational thinking—basically, students are just writing a few lines of code to do a calculation they could easily do on a calculator. But I do think it provides students with a tool to explore spectral lines a bit more and start to develop some insights about the relationship between transition energy and wavelength, and with the right prompts, insight into what sorts of transitions will produce visible spectral line, which might give a bit more meaning to the sea of names for spectra we have—did you know that we have names for 6 different series? Lyman, Balmer, Paschen, Brackett, Pfund, and Humprheys? Honestly, before I started working on this program, I had no idea why there were even separate names for these series, but I now see that they’re named according to the final energy level of the transition.

## Sabbatical goal—visiting 25 classrooms both real and virtually

I’m now mostly settled into life in Norway and despite a few challenges, really loving Scandinavian life (read all about it in our sabbatical blog, A Year in Norway).

I’m going to starting work at the University of Oslo in a week, and I’ve begun to think of goals for this year. One goal I have is to visit a lot of classrooms and talk with many physics teachers. Unfortunately my Norwegian hasn’t made a ton of progress, thus I’m going to need to reach a bit farther afield to find some teachers to connect with.

My goal is to visit 25 classes/teachers this year. A long time ago, I wrote about virtual coaching, and a few intrepid folks signed up, and we ran some great sessions—I think I saw a couple of physics classes and even a Spanish class, and had some stimulating conversations with the teachers of those classes.

This year, I’d like to bring this project back, and I’m hoping that you might be willing to invite me into your classroom. Since I’m on sabbatical, and my work at the university is likely to be rather flexible, I’ve got a good bit of time on my hands. Here’s a rough idea of what I’m thinking:

- We set up a pre-visit chat where we discuss your class and you let me know what you’d like me to observe.
- I visit your class virtually, which would likely involve you setting up a laptop or tablet with skype or zoom and livestreaming your class to me.
- We set up a debrief to talk about what I saw.

If you’ve got a different idea in mind, I’m open to modifications to this structure. If you’re interested in seeing if this could work, then please fill out this interest form.

## A tale of two museums

*(Note: I’m cross-posting this post from my sabbatical blog, A Year in Norway, since I think some of my regular physics teacher readers might find it of interest).*

During our week in Paris, we had the chance to check out two science-related museums, the Musée Curie, and the Cité des Sciences et de Industrie.

I decided to write up this visit in the form of a letter to the curators of the Cité des Sciences et de Industrie that I will be mailing soon. Read on, and you will understand why.

Dear Curators,

Last week, I had the pleasure of visiting your museum with my wife and two daughters. My eldest Daughter, Maddie (age 7), has developed a passion for all things science, and physics in particular, so our first stop was the exhibit on the Great Story of Our Universe. As a high school physics teacher, I was eager to explore this exhibit with my daughter.

At first, I was struck by just how beautiful the exhibit was—your designers did a marvelous job of creating a inviting space that wonderfully used lighting and texture to evoke a flow through the origin of our universe, with great hands-on experiments that allowed you to touch and view meteorite samples, or see a live infrared photo of oneself to understand how we are able to classify stars based on the light they emit.

Maddie looking at some meteorite samples.

I was particularly impressed by so many of the simple but engaging experiments—a parallax experiment that explained how we measure the distance to stars, by demoing how to make a measurement of a “star” on the wall across the room. My favorite demo of all was the side by side model solar system and galaxy, and the text that invited the patient to see how these two models behave very differently. Maddie and I watched it for at least 5 minutes, and she made so many observations about the differences she saw. What a wonderful introduction to Dark Matter.

After getting through the first floor of the exhibit, I was pleasantly surprised to see it went to a second floor that explains the strange physical laws that “enable us to describe and understand the evolution of the Universe.” Here again, I was impressed with all the interactive exhibits and even more impressed with your efforts to explain not just some of the oldest physical laws like gravity and electromagnetism, but also to fully cover discoveries in quantum mechanics (we loved Schrodinger’s Cat in a Box), and even some very recent discoveries in cosmology.

As I walked around this exhibit, I began to notice something strange—every column in the exhibit featured the name and biography of a famous physicist or mathematician, and every single one of them was a male. I’m also pretty sure that they were all white European men—Newton, Galileo, Descartes, Schrödinger, Lorentz, and on and on—more than 20 names in total. I looked hard, and I didn’t see a single woman or person of color in the entire collection.

In another part of the exhibit on the second floor, there was an exhibit presenting nine quotes about the nature of the universe from scientists and philosophers throughout history, and every one of them came from a white man, as best as I can recall.

It’s easy to come away from this exhibit thinking that our entire understanding of the universe, and the field of physics, is the result of the work of a bunch of dead white dudes with gray hair and more often than not, a mustache, leaving out so many important stories of women who have contributed to this understanding and what the field of physics looks like today.

There are so many incredible women scientists who have made deep and profound contributions to this story, that I find it hard to understand how they could all be left out of this exhibit. Adding a description of Vera Rubin and her groundbreaking work on galactic rotation curves would have have been an informative and powerful addition to the first-floor exhibit about the rotation speeds of galaxies and our solar system. Marie Lavoisier, Marie Curie, Joycelin Bell, Henrietta Leavitt—each of these women made major contributions to experiments and discoveries that were already mentioned or alluded to in your second-floor exhibit, and they have inspiring and important stories that are worth sharing with visitors to the exhibit.

With the exhibit’s vast amount of space and focus on highlighting recent discoveries in physics, I can imagine a wonderful addition that highlights very recent discoveries in physics—like the discovery of gravitational waves, showing photos of the hundred-person plus team that made this discovery. A wall featuring photos and descriptions of scientists today could very well inspire many of your youngest visitors to see themselves as scientists and imagine how they might contribute to understanding the universe when they grow up.

This exhibit also raises the opportunity to talk about why the field of physics has been historically dominated by men—specifically pointing out the ways in which women have been excluded from educational opportunities and research organizations since practically the beginning of science. At the same time, you could point out the hidden and unrecognized ways in which women have made vast contributions to the field of physics—from serving as the “human computers” to painstakingly type the dissertations of their husbands. Perhaps this conversation looking at the nature of who does physics could be a web resource, similar the great ones I saw on the ground floor in Cite des Enfants, where the signage encourages parents to visit a website for more ideas about how to engage children in the experiences they had in the museum.

I know that museums are incredibly powerful places—they are some of the most important places for inspiring young people and opening their minds to possible careers and ideas they would not have otherwise considered. This was made most clear to me in the case of my own daughter, who developed a love for Marie Curie after reading a short story describing her life in “Goodnight Stories for Rebel Girls.” After reading that story, Maddie decided she wanted to be a scientist just like Marie Curie and wanted to know all she could about the Nobel Prize. When Maddie read in the story that Marie Curie lived in Paris, she asked us if we could visit her house, and through that, we discovered the wonderful Museé Curie, a tiny three-room museum dedicated to the life of Marie and Pierre Curie. Maddie pushed this museum to the top of our Paris agenda, and watching my daughter in this space was magical. Maddie was thrilled to see Marie Curie’s office just as it existed, but she spent the most amount of time scrolling through images of Dr. Curie and her family on a large video screen, occasionally fixating on a picture of Marie Curie on her wedding day. Maddie has been super fascinated with weddings recently too, and when we talked about it leaving the museum, she told me how awesome it was that her hero, Marie Curie, was also able to get married. To me, this visit scored the trifecta of science museums—it helped my daughter to not only understand an important discovery in science, it helped her to relate to the story of the human that made that discovery—emphasizing her humanity and helping my daughter to see that she too can be a scientist.

Maddie in Marie Curie’s office.

I wish we had more time to explore your museum. I’m sure I missed many exhibits that did celebrate the work done by women in science, and help students of all backgrounds seem themselves as scientists. I appreciate your consideration of these suggestions and look forward to visiting the museum again in the not too distant future.

Sincerely,

John Burk

Physics Teacher and Dad of wonderfully curious 7-year-old girl who wants to be a physicist