The Tesseract Project A blog of temporary obsessions

Some STEM Questions for 2021

What with a pandemic and crazy politics in 2020, it seems I've heard a lot less lately about STEM ("Science, Technology, Engineering, and Math") education lately. There are a lot of gaps in my understanding, and what I come across doesn't all seem to add up. So one of my goals for 2021 is to understand it better.

Here's a list of questions I'd like to learn more about during 2021. They aren't the only questions, and probably not the best questions. But it's a starting point.

  1. From the narrow, somewhat random examples I have seen, STEM programs seem to be mostly about Technology as meaning "computing" and E for simple engineering projects. Are science and math not getting much emphasis?

  2. Do simple projects engage many students in non-computer science STEM pursuits?

  3. Sometimes it seems like there's an underlying assumption that cool computer activities or building things "like engineers" will somehow pull students into being excited about learning the core science or mathematics. Is that the plan? Is there evidence that it works? Are there ways to encourage intrinsic interest in math and science subjects?

  4. Where are the shortages of scientists, engineers, and mathematicians? When business leaders talk about "we can't find enough good engineers", do they mean something more than "we need more programmers"?

  5. It seems that many (most?) engineering schools require students to apply to them as incoming first-year students and have strong requirements for science and math background. This would seem to limit the field, since students don't have the opportunity to explore much about engineering, or to catch up on the foundations.

  6. Has the number of available slots at engineering schools been increasing at the necessary rate? If not, why not?

  7. Anecdotes suggest that engineering schools have been expanding the required curriculum of engineering courses, limiting students' ability to explore and learn about other areas. As job preparation, that's understandable. But it would also seem to limiting the range of knowledge for a full life, as well as diminishing the students' abilities for making choices and decisions about human issues as they advance in their careers. Is this true? Is this also happening in the sciences? Are these pressures from industry?

  8. At the same time we hear complaints about "not enough engineers", we also hear about how older engineers are forced out of their jobs because "things have changed". Change in science and technology is inarguable, but that seems like sacrificing an enormous amount of valuable experience. How much is this going on, and what alternatives might be possible?

  9. Another career problem for engineers seems to be that many companies focus on a promotion track that rewards moving into management but not staying in a technical role. What are some ways to value continued technical work?

  10. Has computer science pulled in many students who would otherwise have pursued other STEM paths, creating shortages in those areas?

  11. We seem to have a culture where it's perfectly fine to say "Oh, I'm not a math person" and give up on it. Why is that? Can that culture be changed?

  12. It would seem that not teaching evolution in schools cuts many, many students off from continued study in biology, bioengineering, biochemistry, medicine, and anything else in the life sciences. How does this affect the pipeline of students in those fields?

  13. Along the same lines, it seems that politically "STEM" is popular, maybe only as long as it focuses on things like computing and building bridges. Those aren't the areas with anti-science attitudes come out. Is that why the focus seems to be on those? How do we expect to do better at STEM broadly with anti-science attitudes?

  14. Math is part of all of this, but seems not to get much attention except in fights over math curricula and teaching methods. What's going on in the math corner?

  15. What are some useful ways to think about "STEAM" (adding "Art" into the mix)? On the face of it, a focus on STEM that de-emphasizes learning about the arts is sacrificing a huge swath of the human experience. Not knowing something about art diminishes the engineer's creativity in designing to solve human problems. This seems to be a common argument for sufficient funding and student time for the arts, to complement STEM. And I think that many people simply react as "one of those things is not like the other". Art matters, and not just as support for engineering. I'd like to learn more about these approaches, as well as the simple idea that art in the schools matters.

I'm sure there are many more questions that should be on the list. What am I missing? Send suggestions by email to treese@acm.org or on Twitter as @wintreese.

I hope to report back later in the year.

It's 2021, and we're still talking about fax machines

At least a little bit.

On an airplane flight, in the early-to-mid 1990s, I had an epiphany: fax machines were apparently a big deal, and I had completely missed their rise. The insight occurred from one too many times looking at the airline in-flight magazine, and noticing all the fax-related ads. Apparently business people needed them.

The reason I missed the burst of fax machines was that I was using email relatively early. I don't claim this as special status; it also apparently isolated me from something affecting a lot of other people.

It's easy to think that email has killed fax, but apparently it hasn't. In the final month of 2020, the New York Times mentions fax in articles about neo-nazi threats in Germany, health care workers expecting to get coronavirus information from states by fax, and trying to get a comment from the government of China about actions in Hong Kong. If fax is on its way out, it's taking its own sweet time.

Back in 2015, James Coopersmith published a book called Faxed: The Rise and Fall of the Fax Machine (Johns Hopkins University Press), documenting the fax story from its invention in 1843 (before the telephone!) to its apparently disappearance by 2010. There was a nice overview of what happened from the BBC in 2015: Why the fax machine isn’t quite dead yet.

Apparently it's still not dead. But it might be hard to find one by the 200th birthday of the fax in 22 years.

The Zombie Office of Zoom

One effect of the 2020 pandemic has been to flatten many office workers from cubes in the office to squares on a screen. The workers, and many of their organizations, have learned a lot from this experience. Remote work is often more possible than expected. Meetings on a screen are harder than meetings in person. Separating work from home is more challenging when you are always at home. Commutes may be annoying, but they also offer a buffer and time of transition from home to work and back. Being on Zoom all day can be exhausting in a way that physically being in an office is not.

I happened across a book review, The Road to the Zombie Office, written by architecture critic Martin Filler from the June 19, 2014, edition of The New York Review of Books. The book in question is Cubed: A Secret History of the Workplace by Nikil Saval (Doubleday, 2014). Filler's review is both thorough and fascinating, although in the midst of a pandemic that has scattered us from offices, it feels like an exploration of bygone days.

But that doesn't mean it isn't relevant. His essay, and likely the book itself, which I have not read, can help us think about how offices might work in the post-pandemic, post-all-Zoom world. We have an expanding array of technological tools claiming to eliminate the need for the office, yet they all lose some aspect of human interaction that we may notice only when it's not there. There are real opportunities for organizations that figure how to blend these things well, and real dangers for organizations that fail to do so.

Filler concludes his review with an idea we should take seriously as we eventually emerge from the isolation forced upon us by the pandemic:

What has not changed much throughout the two centuries that Saval examines in his delightfully readable, sporadically penetrating, and regrettably uneven study is the still-persistent belief that the physical aspects of an office will strongly affect the quality of work produced there. This is often an illusion. For, as with all other architecture and design, the way we make our offices offers an accurate reflection of our values, and not a formula for improving them.

There's a long history of business drives to efficiency in office work and in knowledge work, often with side effects predictable and not. The pandemic has jolted the system, and the lesson is that if we want the newly reconstructed workplace to be better, we need to think carefully about the values and choices guiding its design.

The growing periodic table

This morning I came across a note I made in 2011 that a new chemical element had been announced, and at the time, I wondered when the one before that one came. I hadn't heard about them any new ones in a long time.

Apparently I have just been missing the news. In fact, I feel like I've missed most of it since Bohrium (element 107, 1981) and perhaps since Seaborgium (106, 1974). I vaguely recall numbers up to around 105 or 106, but I don't remember ever hearing those names. It feels a bit embarrassing, especially since we're up to 118 (Oganesson, in 2002), although the most recent one is Tennessine (117, in 2009). (Names, numbers, dates are from the Wikipedia Timeline of chemical element discoveries, and of course that's a page that exists.)

The 2011 announcement I had noted was about Flerovium (114, originally discovered in 1998) and Livermorium (116, in 2000). They were both synthesized in Dubna, Russia, at the Joint Institute of Nuclear Research.

There's too much to the story of element discovery even in the past decade to get into right now, but there are some interesting stories about the science, the people who did the work, arguments between chemists and physicists about elements, and the organizational details of accepting and naming new elements. Some approachable articles that go into various aspects of that are:

And the next ones may be more exciting, because new ones will suggest another row in the periodic table, and that implies some different chemical properties.

A little probability question in DC

Here's a little math question. But wait! Before you go, "Blah, blah, math" and click away, take a quick look at the question, and then the story behind it.

Suppose you have an urn with eleven marbles in it. There are two green marbles, seven yellow marbles, and two agates. You take out the agates because this problem is only about the solid colors, leaving you with nine.

If you pick three marbles out of the urn at random, what's the probability that you'll get both green ones?

You might be thinking, "No one cares about urns with marbles in them." Or, maybe "Probability problem! Awesome!". Or, "When would I care about that?"

The answer to the last question might be "last Friday" (that is, August 7, 2020). On that day, the US Court of Appeals for the District of Columbia Circuit ruled that the House of Representatives can pursue its lawsuit to compel former White House Counsel Don McGahn to testify before the Judiciary Committee. I have no idea about what will happen with that, but here's how we get to the math part.

  1. A district court judge ruled that the House suit could proceed.

  2. A three-judge panel at the DC Circuit ruled 2-1 that it could not.

  3. The House appealed for an en banc hearing of the whole court.

  4. After two of the eleven judges recused themselves, the remaining nine heard the case.

  5. The full court ruled 7-2, with the two original judges who voted to dismiss in the minority.

Arguably, any three-judge panel that did not include both of those judges would have ruled differently in the initial appeal.

I learned about this from the Cafe Insider Podcast, hosted by Preet Bharara <>and Anne Milgram, who wondered about the odds of this.

So: What's the probability that such a panel would be been selected?

Well, it's exactly the same problem as our urns and marbles!

So let's figure it out.

We can list the possible combinations of marbles (or judges) that would include both the green ones: GGY, GYG, and YGG. It seems intuitive that the probability of any of those should be the same. That intuition is correct, so we won't prove that here.

So let's focus on the first possibility. If we think about picking the marbles out of the urn one at a time, the probability of getting a green one on the first draw is 2/9 or two out of nine, because there are two green ones out of a total of nine.

Now there are eight left, and the probability of getting the other green marble is 1/8, for the same reason.

So 2/9 of the time we get a first green one, and 1/8 of the time after that we get the other green one. These are what are called "independent events", because they don't have anything to do with each other, and when you've got independent events you can multiply the probabilities. So 2/9 * 1/8 = 2/72 (As Tom Lehrer might say, "'Fractions? I didn't know there would be fractions!' I hear you cry.")

And we've got three ways that can work out: GGY, GYG, YGG. That's three possibilities with the same probability, and 3 * 2/72 is 6/72, which reduces to 1/12.

If we want to say this as odds, we give it as a ratio of the number of times a thing happens vs. the number of times it doesn't. A probability of 1/12 has one time where it happens and eleven where it doesn't (on average), so the odds would be 1:11 in favor, or 11:1 against.

Thanks to my brother-in-law for this approach to it. I solved it a different way at first, but his approach is easier to follow, I think.

Lamport - A Fast Mutual Exclusion Algorithm

I recently came across (again) a copy of Lelie Lamport's 1987 paper, "F Fast Mutual Exclusion Algorithm"1. It's a gem of a paper.

What do you do if more than one program on a computer wants to use the same resource? That's the problem of mutual exclusion. With a single processor, it's easy: when a program needs the exclusive access to the resource, interrupts can be turned off so that it can finish the critical section of its work. Then another program can use it.

If you're building a system with multiple processors, it's much harder. The problem was first formulated, along with a solution, by Edsger Dijkstra in 19652. In practice, multiprocessor machinese were typically built with an atomic test-and-set instruction, which also makes it pretty simple. In the 70s, as experimentation with multiprocessor systems evolved, there was a fair bit of research on things like mutual exclusion with things like message passing, since shared memory wasn't necessarily available.

Lamport joined Digital Equipment Corporation's Systems Research Center (SRC) in Palo Alto in 1985. Not too long after he got there, some of the researchers at DEC's Western Research Lab (WRL), also in Palo Alto3, were designing a new multiprocessor system (presumably Multi-Titan), and they were wondering if there was a way to avoid adding synchronization instructions to the CPU in single processor system (Titan) they had already designed. Earlier work on mutual exclusion had paid a lot of attention to avoiding starvation—the idea that the critical resource might be so busy that a process would never get access to it unless the algorithm guaranteed it. Based on experience with multiprocessor systems, the WRL team expected that contention for critical sections was actually rare in practice, so maybe there was a way to do it fast enough using shared memory without special CPU instructions.

Software developers often think of theoretical computer science theory as being fairly removed from what they do every day. In fact, there's an enormous amount, mostly invisible, of the software world built on decades of work in theory. And sometimes, you encounter a "real world" problem that actually raises an interesting question that can be answered with a theoretical approach.

This was one of those times.

So Lamport proceeds to figure it out, finding the lower bound on the number of memory operation required and an optimal algorithm to do it. In the paper, he walks through a process of deriving the algorithm from the constraints of the problem, which gives a clear understanding of each step in the algorithm, why it's there, and why you can't get rid of it. The paper goes on to give formal proofs of the algorithm's correctness and that it won't deadlock.

Lamport's papers are usually very clear and, for the material, easy to follow. This includes the proofs, although not every reader is interesting in going through the level of detail that proofs require. The description of deriving the algorithm is a polished diamond of presentation.

In the end, the algorithm wouldn't provide the performance the WRL team wanted, and they ended up adding the instruction. But they were able to do that with the knowledge that they didn't really have the choice—there wouldn't be any regrets or wondering what they might have done if they had just been smarter—and they could clearly justify the extra cost in the project.

Leslie Lamport won the Turing Award in 2013, and is also well-known for creating LaTeX. He also keeps a nice list of his publications with some commentary about them.4

As a side note, this is an interesting example of the challenge of assigning dates to papers. It was originally dated November 14, 1985, revised October 31, 1986, published in TOCS in February, 1987, and, judging by the copyright date, issued as a technical report by Digital Equipment Corporation in 1988.


1

Leslie Lamport, A Fast Mutual Exclusion Algorithm, ACM Transactions on Computer Systems 5(1), February 1987, pp. 1-11. Technical report version (revised 1986) at https://lamport.azurewebsites.net/pubs/fast-mutex.pdf

2

E. W. Dijkstra. 1965. Solution of a problem in concurrent programming control. Communications of the ACM 8, 9 (September 1965), DOI=http://dx.doi.org/10.1145/365559.365617 10.1145/365559.365617

3

About two blocks away. Why were there two research labs there at the same time? That's another story.