Alden Bradford

An old statistics exam

2025-10-17T00:00:00-04:00

As I write this, my college is having technical issues with Canvas and with student email. I will extend homework deadlines to accommodate students, but I also want to make sure all students have an opportunity to study effectively for their exam on Monday. So, I am sharing a past exam here on my personal website.

Here is the old exam.

Here is the grading key for that same exam.

Pass the Pigs for Teaching Statistics

2025-06-02T00:00:00-04:00

The problem

Most people don't understand empirical probabilities. There is a common misconception: if a random event has two outcomes, then it is a 50/50 chance of each outcome. One of my goals teaching introductory probability is to replace that misconception.

The simplest way would be to take something with known, obvious probabilities and use them to construct other probabilities. Take a 6-sided die, and it is obvious from symmetry that each side has a 1/6 chance of showing. From that we could compute the probability of rolling at least a 3 -- there are four atomic probabilities, so the probability is 4/6. There are two problems I see with this. First, not every probability model can be broken down into equally likely "atomic" probabilities. Take a coin weighted with $P(heads)=1/\sqrt{2}$, for example -- the probability is irrational. Second, it kicks the can down the road: students are still left with the idea that all "atomic" probabilities are equally likely, if we can only identify what those probabilities are.

One way I like to deal with this is by having my students roll Hershey's Kisses as dice. From my experience, they land flat-side-down around 30% of the time. This is far enough from 50% to convince the students that it's not a 50/50, yet still big enough to use a normal approximation for the sample proportion without an enormous sample size. More importantly, it is not clear how, if indeed it is possible, we could arrive at the probability from a theoretical perspective. I can think of a few different methods which give slightly different theoretical probabilities. Perhaps in a future post I will share a couple of those methods. For now, the point is: if you want to know the probability for sure, the best way is an empirical approach. The process is clearly random, but without the symmetry which is so common in toy problems. It also has a more visceral feel than, say, a spinner problem. Those always seem a bit constructed, artificial. The candy is something students encounter in the world outside of math class.

The Hershey rolling activity is great for broaching the topic of empirical probability, and it can segue nicely into inferential statistics. Natural questions arise -- how many times would we have to roll it to find the probability to the nearest percent? Does our sample show one theoretical model is better than another? Does the rolling technique or surface affect the probabilities? This is the kind of richness I want for every in-class activity. I would like to use a similar approach for teaching random processes with more than two outcomes.

Enter the Pigs

Pass the Pigs is a game based on the classic press-your-luck dice game, Pig. The twist is that, instead of regular 6-sided dice, it uses dice shaped like pigs. There are six orientations a pig can land, so it is still in some way a six-sided die. From the shape of the pigs, it is obvious that some sides will fall more easily than others. There is no symmetry in the pig -- not even bilateral symmetry. And perhaps best of all, the pigs are available in bulk from Math 'n' Stuff. My college ordered a class set of 100 to use.

I am not the first math teacher to use these dice in this way. Back in the late 1990s and early 2000s, Dean Ballard was an instructor at Lakeside School in Seattle. He put his student to rolling pigs in search of an empirical probability, and his rolls were published online. This gives us a baseline for what to expect. Incidentally, that website says it was written by Freddie W. Could this be the same Freddie Wong who is now an internet celebrity? He attended Lakeside School at around the right time! Ballard's numbers are cited in an interesting paper from 2004, Optimal Play of the Dice Game Pig.

I wanted to give my students some practice with Chi Squared tests, so I set them to rolling pigs to get some new data. The first task was to decide as a class on a sample size. Using the estimate that Leaning Jowlers show up 1% of the time, we conclude that we need 500 rolls all together to be able to apply the goodness-of-fit test. Too many for one person, but with the whole class working together each pig only needs to be rolled and counted 5 times.

I recommend dividing students into groups of 2-4 students to do the rolling. It is much more engaging when you can count together, and it produces better discussions about how to keep track of the work. I project a QR code to a survey where each group can upload their totals. Then it is a simple matter to copy the results from an online spreadsheet, which students can also get to with a QR code. If you teach this lesson, you could build your own form, or use the same one. By sharing the same spreadsheet we can have a pretty big sample size.

I was surprised to find my students got significantly different results from Ballard. They found around 2% each of the snouters and leaning jowlers, about 30% razorbacks, and only 6% trotters. I can't explain why there is such a difference, but it does seem to be real.

Additional exploration

Why the discrepancy? It could be that the razorbacks were preferred because I had my students rolling several pigs at once. Rolling next to other pigs may have caused them to naturally align. Could the results be different if we rolled fewer at a time? What if we drop them from a greater height? What if we roll them out of a dice cup, rather than from the hand? This activity has some room for exploration, at a level which is accessible to first-time statistics students. I hope to use it for more inquiry-based learning in the future. For now though, it is a refreshing way to get hands-on in what would otherwise be a relatively theory-heavy part of the quarter.

We should all use OpenIntro Statistics

2025-05-14T00:00:00-04:00

Background

In Washington State, we teach a unified statistics curriculum across all the community colleges. The course is called Math&146, and our rule for what goes into it is the American Statistical Association's Guidelines for Assessment and Instruction in Statistics Education (GAISE) College Report. Currently, most instructors at Olympic College use the OER textbook Introductory Statistics published by OpenStax. I believe we should transition away from the OpenStax textbook, and instead adopt a different OER textbook, published by a different group with a similar name: OpenIntro.

Introductory Statistics, published by OpenStax, has two primary authors and eight contributing authors. The primary authors were professors at De Anza College, a community college in Cupertino California. They are both now retired. One of them has a master's degree in statistics and a PhD in education, and the other has a master's degree in applied mathematics. Out of the eight other contributing authors, one has a master's degree in statistics. The rest have degrees in mathematics or related disciplines.

OpenIntro Statistics was created by three PhD students at UCLA, each of whom completed their PhD in statistics. Two of them later did postdocs in statistics, one of them is now a statistics professor at Duke University. It is currently in its fourth edition, with a fifth on the way. This is a mature textbook, the first edition being published in 2011. Also, unlike the OpenStax book, OpenIntro has the approval of the American Institute of Mathematics Open Textbook Initiative.

I have a few different reasons I think we should switch, and it amounts to more than just a matter of personal preference. On a couple key topics, the exposition given in OpenStax is arguably incorrect from a statistical point of view. More broadly, OpenIntro has better alignment with the standards laid out in GAISE, in ways I will explain below. I think this difference can mostly be attributed to the different backgrounds of the authors. The OpenStax book was written by mostly mathematicians, while the OpenIntro book was written entirely by statisticians. Particularly since we have more mathematical expertise than statistical expertise among the faculty here at Olympic College, it would be better for us to use the book with a stronger statistical bent.

Necessary improvements

We could argue about preferences indefinitely and never reach a conclusion. There are lots of stylistic, pacing, and presentation choices which matter a lot for textbooks. There is no one best way to write a book. That's why I want to start with a couple of things which are not just preferences. There are two major areas where OpenIntro Statistics is right, and OpenStax is wrong. Even if you do not switch to OpenIntro, you should be aware of these problems so as to limit the spread of false statistics information.

Retrospective One-Tailed Tests

There is a fundamental issue with how OpenStax structures the hypothesis testing chapter. Consider the Try It example 9.19 from the OpenStax text:

A car soap gets rid of 30% of stains on the car. After adding a new compound to the soap, the soap is used on a car and found to wash 20 stains out of the 50 stains on the car. With the level of significance being 10%, find out if adding the new compound to soap is beneficial.

We know that 40% of stains in the sample were removed, we want to know if that difference is statistically significant. I will set aside concerns about whether the stains are really independent events. On problems like this, the OpenStax text instructs you to do a one-tailed test. Using the null hypothesis value of $p=30\%$ we would expect to see samples where at least 20 stains are removed about 8.5% of the time. That's less than our rejection threshold of $\alpha=10\%$, so we reject the null hypothesis and conclude the new soap is beneficial.

That's the solution OpenStax expects. That solution is also wrong.

To understand the error, let's see what would have happened if instead of 20 stains, the soap managed to get rid of 10 stains. If this had happened, we would have asked: with a significance level of 10%, is the new compound detrimental? Again, using $p=30\%$, we would expect to see samples where at most 10 stains are removed about 7.9% of the time. That's less than the threshold of $\alpha=10\%$, so we reject the null hypothesis and conclude the new soap is detrimental.

I hope the error is becoming clearer. The problem has us inspecting the data before we decide what test to use. Following the OpenStax procedure, we end up rejecting the null hypothesis $8.5\%+7.9\%=16.4\%$ of the time, assuming the null hypothesis is true. That should not be possible with the significance level chosen. $\alpha$ is meant to be the probability of rejecting the null hypothesis assuming the null hypothesis is correct. We should have done a 2-tailed test, and we should not have rejected the null hypothesis at all.

Some of the problems in OpenStax are more carefully worded, and make it clear that the researcher picked the test to use before inspecting the data. Not all of the questions are so careful. Any time we inspect the data before deciding on which direction of test to use, we must do a 2-tailed test. Otherwise, we end up doubling our $\alpha$ value by mistake.

For this reason, the OpenIntro book defers one-tailed tests to a special topic. Most of the book avoids one-tailed tests.

It is true that there are cases where a one-tailed test is appropriate. For example, when you try a new treatment against the null hypothesis of "this does no better than the best currently established treatment", it makes perfect sense to do a one-tailed test. You will get a little more statistical power that way. However, for almost every case our students are likely to encounter, it is safer to just do a 2-tailed test every time. Some disciplines have banned one-tailed tests entirely, because they are so often misapplied. When I teach Math&146, I do not cover one-tailed tests. The consequence is that the rules for students to learn are simpler, and the students' results are more accurate. That's a win!

For a nuanced discussion of this issue, see Misprescription and misuse of one-tailed tests (2009), When should we use one-tailed hypothesis testing? (2010) and One-tailed tests: Let's do this (responsibly) (2024).

T test or Z test

There are several places in statistics where a z-test is always the right test to do. For example, when we are computing a population proportion confidence interval, we are safe to use a z-score whenever $np\geq 10$ and $n(1-p)\geq 10$ because the central limit theorem kicks in very fast for the binomial distribution. Since we use the binomial distribution formula to compute the standard deviation, we don't need the small-sample correction that Student's T distribution provides. One of the improvements of the OpenIntro text is that it starts the inferential statistics section looking only at sample proportions. With only the normal distribution to compare against, students have more energy to pay attention to the hypothesis testing framework -- terms like standard error, point estimate, confidence interval, and p value. Later on, once students are used to the framework, we introduce the t-test.

When I was first taught statistics, I was taught to use a t-distribution for sample sizes less than 30. For larger samples, we were told to use the z-distribution since the t-distribution converges asymptotically to a standard normal distribution when the sample size is larger. This is the strategy taught by OpenStax. When I was a kid, this made sense -- the textbook only had t-tables for sample sizes up to 30. These days, most people are not looking up values in a table, they are using computer software to find the t-scores. When you have a computer on hand, it does not make sense to deal with a special case for large samples. It is much simpler to just use the t-distribution for anything where you are using the sample variance. The CDF is a hypergeometric function, which is one of the fastest types of special function to compute by machine. The OpenIntro book teaches students to use a t-score regardless of sample size. This method is easier to remember, less prone to error, and gives slightly more accurate results. That's a win!

As an aside, I will note one other case where OpenStax advises students to use a z-test. That's in the case where the population standard deviation is known, but the population mean is unknown. From a mathematical standpoint, this approach is sound. From a statistical standpoint, it is unfounded. There are almost no cases in practice where you would know the standard deviation of a population but you would not know the mean. This case has some merit as a teaching tool, a stepping stone, emphasizing the reason why the t-test is necessary. I believe this would be a worthwhile special topic in a more advanced probability class, particularly one where students will derive the t-test for themselves. It does not belong in an introductory stats class. OpenIntro does without it.

Technology

Modern statistics is not done without computers. GAISE exhorts us to

-5. Use technology to explore concepts and analyze data.

Two of the Goals for Students in Introductory Statistics Courses are

-3. Students should be able to produce graphical displays and numerical summaries and interpret what graphs do and do not reveal.

-8. Students should be able to interpret and draw conclusions from standard output from statistical software packages.

OpenIntro and OpenStax are built around different computer tools. My philosophy for choosing a tool is that it should have a low floor and a high ceiling.

A low floor means that students should be able to get useful results after just one 50-minute lesson using the tool. This precludes a general-purpose programming language like Python. In my experience, it takes at least two lessons in Python before students are comfortable enough with the syntax to be able to import the required libraries and use the relevant functions.

A high ceiling means that students should be able to continue to use the tool throughout their education and career. The tools that we teach should be powerful enough that students will not have to abandon them when their next course, or next job, comes along.

The TI-84

Every problem in the OpenStax book can be solved using the TI-84. There are even helpful guides sprinkled throughout, explaining exactly which buttons to press. This tool definitely meets our low floor criterion. Many, possibly most, of our students have used a similar calculator in high school. Students can often get useful results without any new instruction on our part. Unfortunately, the TI-84 does not have a very high ceiling. It is hard to load data onto it. It is not practical to export the graphics it creates. Even as we teach Math&146 now, we often supplement with web applets that do much better than the TI-84 at specific tasks. There was a period in the 80s and 90s when it would have been an acceptable tool for a professional context, but that time has long since passed.

Why does OpenStax use the TI-84? I believe this can be traced back to Texas Instruments' educational outreach division. In order to maintain their market dominance in the high school education space, TI has produced excellent educational resources to help high school teachers prepare their students for standardized tests, notably the AP Stats exam. The authors of the OpenStax book made an effort to incorporate the TI-84 emulator into their curriculum, which Texas Instruments made free for anyone to use, as a way to promote the use of the calculator. Using those educational resources was an economical way to get technology into the curriculum, helping OpenStax get established quickly.

I am a fan of Texas Instruments. Their calculators are excellent. They are the makers of my personal favorite calculator, the TI-30Xa. I still think the TI-84 is the wrong tool to teach college statistics.

Spreadsheets

By far the most common statistical tool used in industry is the humble spreadsheet. No matter what our students end up studying, no matter where they work, they will have access to spreadsheet software. Lots of tasks in intro statistics can be handled with a spreadsheet alone: means, medians, quartiles, standard deviations, even some chi squared tests can be done without leaving the spreadsheet. Students don't need much instruction to get underway with a spreadsheet because many of them have used spreadsheets in other contexts. The graphical interface means spreadsheets certainly meet our low floor criterion. Some people make whole careers out of spreadsheet wizardry, so it also has a high ceiling.

I teach my students to use spreadsheets for data acquisition, data cleaning, and basic summary statistics. I teach them using LibreOffice Calc, which is a free spreadsheet program available on every operating system. The skills are transferable to other spreadsheet programs.

I don't leave it there. Once students know how to format their data correctly, I proceed quickly to R.

R

R is a completely free, open-source statistics and data visualization package which has been around since 1993, based closely on its predecessor S which was created at Bell Laboratories in 1976. Unlike Python, it is not meant as a general-purpose programming language. Rather, it is designed specifically to simplify routine statistics tasks. All interaction in R can be done through a command line, and the commands are simple enough that my students rarely have trouble formatting them correctly. Here is an example of an R session a student might use to answer a homework problem.

> x <- c(1, 1, 2, 2, 3, 5, 7, 10)
> summary(x)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  1.000   1.750   2.500   3.875   5.500  10.000 
> sd(x)
[1] 3.226564
> boxplot(x)

Unlike many simple applets, R will correctly terminate the whiskers at $1.5\times IQR$ away from the quartiles. This is how it behaves without any additional configuration. R satisfies the low floor criterion: my students are eager to start using it for their homework the day they learn it.

R also has a very high ceiling. It is a tool used by professional data scientists for exploratory analysis, simulation, and creating publication-quality graphics. You may have seen the popular website FiveThirtyEight. They used R to generate most of their award-winning data visualizations. Just as some people have made a career on being expert in spreadsheets, some people make their living using R.

The OpenIntro textbook comes with a set of labs which get students solving problems relevant to the textbook chapters, using R. These are meant for a class with a weekly computer lab session supervised by a teaching assistant. I have adapted several of these into homework projects, with associated in-class lessons. The projects are not very complicated, typically they will take less than an hour to complete. They are mostly graded automatically through Canvas. Their purpose is to get students using the statistical tools on some real data.

GAISE cautions us that

SAS certification, non-introductory R programming, and other more extensive programming topics belong in subsequent courses.

I do not teach my students about string manipulation, looping, conditionals, function writing, or any object-oriented aspects of R. The most basic parts, essentially using R as a calculator, are more than sufficient for what we need.

Using Real Data

GAISE is unequivocal:

Recommendation 3: Integrate real data with a context and a purpose. Using real data in context is crucial in teaching and learning statistics, both to give students experience with analyzing genuine data and to illustrate the usefulness and fascination of our discipline.

On this score, OpenIntro does much, much better than OpenStax. OpenIntro is littered with real data sets, complete with a context and a citation. The included lecture slides also include additional data sets not covered in the main book, so students get more exposure to the process of exploring data. Every example in the text comes with a cleaned-up copy of the data, ready to download from teh website or as an R package. This makes it easy to create your own graphics, follow-up exercises, and tests based on the same data used in the book.

Contrast this with OpenStax. Its data appendix contains only 2 data sets, and their provenance is dubious. Most of the exercises in the book use made-up values. This can be a good thing! A well-chosen example, used to illustrate an important point, doesn't always have to be true. However, we deprive our students when the only examples we give are made-up. It is ubiquitous to use made-up examples in a math class. It should not be so common in a statistics class.

When I taught from OpenStax, I tried to compensate for this by using data collected with in-class experiments. This worked okay. Now that I am using spreadsheets and R, there are many, many more choices of data available. I recommend Vincent Arel-Bundock's list of just about every data set anyone has published for free as part of an R package. Every one of these comes with a description of how the data was collected and suggestions of how it can be analyzed. By picking from these data sets, it is easy to find data with the types of variables I am looking for. Also, in some cases, the students will already have the data on their machine ready to load in R.

It can be tempting to make up examples for short problems, like making confidence intervals for a population proportion. Since we won't work with them very long, it doesn't make sense to spend a lot of time explaining the context. However, these are also some of the easiest examples to find suitable data for. Our library has a subscription to Harper's magazine, which every month publishes Harper's Index. This is a list of brief, interesting statistics from the news. I regularly peruse Harper's Index for examples to use in class or in quizzes. I find that students are more engaged when we use a number from the news, even if the mathematics is the same.

Topic Coverage

Most of the topic coverage overlaps between the two books. Here I will point out a few notable differences, as we transition from OpenStax to OpenIntro.

Stem-and-leaf plots

I love stem-and-leaf plots. They hold a place dear to my heart. I also adore the slide rule and adding machine -- I own more slide rules and adding machines than could ever be practical. Alas, OpenIntro does not cover the stem-and-leaf plot, and I (reluctantly) must agree that it probably does not belong in an intro stats course, at least not any more than a slide rule belongs in an introductory algebra course. It is a neat device, but it is mostly practical when a pencil and paper are the best tools at hand for data visualization. Today, when a histogram is just a few clicks away, there is no need to bother a new student with the rules of the stem and leaf plot. The role of the stem-and-leaf plot is mostly supplanted by the dot plot and the histogram. GAISE cautions us against

Constructing plots by hand. Data displays are now made by computers. Students need to know how to read and interpret them. Instead of spending lots of time creating histograms by hand, use some of that time instead to develop a deeper understanding and ask more challenging questions about what the plots tell us about the data.

I do still have my students create boxplots by hand, with some technological assistance. I feel this is the best way to ensure they can really interpret the whiskers and the outliers. I don't make them compute medians and quartiles by hand, since that process is prone to error. When students mess up computing the median, it is rarely because of a conceptual misunderstanding.

Probability Theory

Here is where my review of OpenIntro is more measured. As OpenIntro was written by statisticians, it carries a statistician's understanding of probability theory. The section on random variables leaves much to be desired. For example, the OpenIntro book comes with a mostly-excellent set of slides suitable for lectures. The slides on random variables include the bold claim that

Random variables do not work like normal algebraic variables:
$$X+X\neq 2X$$

This is nonsense. The whole point of random variables is that they do work just like algebraic variables. What the authors mean here is that, given two i.i.d. variables $X_1$ and $X_2$, the random variable $X_1+X_2$ will in general not have the same distribution as $2X_1$. In particular, while $Var(X_1+X_2)=Var(X_1)+Var(X_2)=2Var(X_1)$, $Var(2X_1)=4Var(X_1)$. This is a useful point to make, but the way the authors make it is confused and a little clumsy.

If I were choosing a textbook for an introductory probability course, I would probably go with one of the texts by Sheldon Ross. Alas, I do not think any OER textbook exists which is up to my standards for a probability book. Luckily, in our case, we are not choosing a book for a probability course. GAISE tells us

The original GAISE report recommended less emphasis on probability in the introductory course and we continue to endorse that recommendation.

I think the OpenIntro text is well-suited to our course, despite its relatively poor coverage of random variables. I just skip those sections entirely. For comparison, the OpenStax book makes no explicit reference to the algebra of random variables. Also, while the above error does appear in the slides, I have not found any similar error in the text itself. The textbook section on random variables is probably not presented the way I would do it as a probability theorist, but the information presented in the book is correct. There is no danger posed to the curious student who reads outside the required sections.

Aesthetics

The OpenStax book borrows from many other OER textbooks, dating back to at least 2007. There is a mix of many different graphical styles, citation styles, and problem formats. Personally, I feel the book has a disjointed tone. The sections don't flow together, making the book hard to read. I think this is part of why so few of our students read the book. Also, the paperback version is laid out based on the online version of the text, with unnecessarily big margins leading to a bulky book.

The OpenIntro book has a much more consistent tone and flow, having been created and maintained by relatively few authors. They make available the configuration files needed to create your own figures in the same style as the book, if you wish. The end-of-chapter problems are of about the same length across chapters. The problems also reference previous problems and examples from the text, which gives a sense of planning and cohesion to the narrative.

Aesthetic considerations naturally take a back seat compared to concerns about accuracy, accessibility, and content coverage. Aesthetics still matters, because it affects how much and how well students will use the textbook. From my experience so far, I believe that my students are using the OpenIntro textbook more, compared to how my students used the OpenStax textbook in the past.

Recommendation

Over the course of, say, the next two years, we should transition away from OpenStax for statistics. I do like many other OpenStax books, but for Statistics, OpenIntro is better. By transitioning we will be teaching our students more accurate information, we will have better alignment with GAISE standards, and our student will have a better reading experience.

I don't expect that we will change textbooks over night. It will take time for professors to learn the new order of the topics, prepare new lesson plans, and prepare new assessment materials. We should be compensated for that time. The number one request I hear from my students in this course is to have more homework. Many of the online problems we use in the OpenStax course could be adapted to the newer textbook. There are many problems in the printed OpenIntro textbook that don't have online randomized versions yet. This is an area where I would welcome collaboration with colleagues more experienced in online homework creation.

An Even More Straightforward Proof of Descartes’s Circle Theorem

2025-02-05T00:00:00-05:00

I was just thinking about this old paper of mine, and I realized that the embargo period has long since ended. That means I can share it with you, for free! Here it is!

The publisher has asked me to share the following with you:

This version of the article has been accepted for publication, after peer review (when applicable) but is not the Version of Record and does not reflect post-acceptance improvements, or any corrections. The Version of Record is available online at: http://dx.doi.org/10.1007/s00283-022-10234-6. Use of this Accepted Version is subject to the publisher’s Accepted Manuscript terms of use https://www.springernature.com/gp/open-research/policies/accepted-manuscript-terms.

Solution to a puzzle on the incircle of a triangle

2023-04-09T00:00:00-04:00

Some times I hang around the math help subreddit. Most of the people posting there are doing some standard homework problem from algebra or calculus, and they get help right away. Every so often there will be a probability question, and those people get help within a day or so. My favorite to see are the geometry questions. Those questions don't always get solved, since they tend to be trickier. That's where I found the following puzzle.

The puzzle

Begin with a general triangle $\triangle ABC$. Construct the incenter $I$, altitude $AH$, and $M$ the midpoint of $BC$. Define $K$ to be the intersection of the lines $AH$ and $MI$. Show that $\overline{AK}$ is equal to the inradius $r$ of the triangle.

Just for convenience, let's also define $D$ to be the point on $BC$ which touches the incircle, so that $\overline{ID}=r$.

This puzzle had me stumped for a few days. I did eventually get a solution which is not too messy, detailed below, thought I suspect there is a nicer solution using more geometry. I enjoyed solving this, and I hope you will to. If you would like to solve it yourself, stop here. Otherwise, read on.

The solution strategy

The main idea is to consider the area of the triangle. We are given an altitude, after all, and altitudes are good for finding areas. We will compute the area of $\triangle ABC$ in two different ways. First, using the given altitude, the area must be $\frac{1}{2}\overline{AH}\overline{BC}$. Second, by partitioning $\triangle ABC$ along its angle bisectors (into $\triangle ABI$, $\triangle BCI$, and $\triangle CAI$) we find another formula for the area, $\frac{1}{2}r(\overline{AB}+\overline{BC}+\overline{AC})$. That is,

\begin{equation} r(\overline{AB}+\overline{BC}+\overline{AC})=\overline{AH}\overline{BC}.\tag{I} \end{equation}

We will use one other fact about the incenter, which may not be immediately obvious.

\begin{equation} \overline{AB}+\overline{CD} = \overline{AC}+\overline{DB}.\tag{II} \end{equation}

Here is a picture-proof of that theorem. Connecting the incenter to each side along a radius, we split the trianlge into three kites. Dividing each in half, we get three pairs of congruent right triangles, all with the same altitude $r$. Equation $\text{(II)}$ simply follows from grouping those triangles and considering their bases.

Besides that, we will only use Pythagoras,

\begin{equation} \overline{AB}^2=\overline{AH}^2+\overline{HB}^2,\qquad \overline{AC}^2=\overline{AH}^2+\overline{CH}^2,\tag{III} \end{equation}

the definition of midpoint,

\begin{equation} \overline{CM}=\overline{BM},\tag{IV} \end{equation}

and similar triangles,

\begin{equation} r\overline{MH}=\overline{KH}\overline{MD}.\tag{V} \end{equation}

If you would like to try it for yourself, have a go at manipulating the above formulas to get the answer. Otherwise read on.

The arithmetic

Depending on the relative positions of $A$, $B$, and $C$, the lengths will add up differently. To make it simpler to follow, we will assume that (as in the diagram above) $H$ lies between $M$ and $B$. The strategy will work in any case, but this will make a world of difference for readability.

Let's begin at $\text{(III)}$, subtracting the two equations to cancel the $\overline{AH}$ term.

\begin{align*} \overline{AC}^2-\overline{AB}^2 &=\overline{CH}^2-\overline{HB}^2\\ &=(\overline{CH}+\overline{HB})(\overline{CH}-\overline{HB})\\ &=\overline{BC}(\overline{CM}+\overline{MH}-\overline{HB})\\ &=\overline{BC}(\overline{BM}+\overline{MH}-\overline{HB})\\ &=2\overline{BC}\overline{MH}.\tag{VI} \end{align*}

Inspired by the difference-of-squares formula, let's manipulate $\text{(II)}$ similarly.

\begin{align*} \overline{AC}-\overline{AB} &= \overline{CD}-\overline{DB}\\ &= \overline{CM}+\overline{MD} -\overline{DB}\\ &= \overline{BM}+\overline{MD} -\overline{DB}\\ &= 2\overline{MD}.\tag{VII} \end{align*}

Do the same with $\text(I)$,

\begin{equation} r(\overline{AC}+\overline{AB})=\overline{BC}(\overline{AH}-r).\tag{VIII} \end{equation}

Difference of squares takes us home, and $\text{(V)}$ lays the problem to rest.

\begin{align*} r(\overline{AC}^2-\overline{AB}^2) &= r(\overline{AC}+\overline{AB})(\overline{AC}-\overline{AB})\\ 2r\overline{BC}\overline{MH} &= \overline{BC}(\overline{AH}-r)2\overline{MD}\\ r\overline{MH} &= (\overline{AH}-r)\overline{MD}\\ \overline{KH}\overline{MD} &= (\overline{AH}-r)\overline{MD}\\ r&=\overline{AH}-\overline{KH}\\ &=\overline{AK}. \end{align*}

Conclusion

As mentioned above, this solution is based on areas, because we are given altitudes. It still feels quite algebra-heavy for a geometry proof. In general, $H$ could lie to the left of $C$, between $C$ and $M$, between $M$ and $B$, or to the right of $B$. Giving all the details of each case would be tiresome, but would make this proof fully rigorous. I can't quite shake the feeling that there must be a tidyer way about this problem, using less algebra and more geometry. For now, I leave it here. I hope you enjoyed this puzzle as much as I did.

Orrell's Quick Wall Paper Calculator

2022-12-05T00:00:00-05:00

My wife got me an early holiday gift this year. It's an ancient trade show promotional item, which must be nearly 100 years old by now. I believe it was made in 1923 or 1924, for reasons which will soon become obvious. In addition to working as an advertisement for L.C. Orrell & Company, it serves as a rough area estimation tool for wall paper.

It consists of a cardboard envelope with two holes cut into it, along with a card which slides inside the envolope. The whole thing measures 5.5 by 2.75 inches. To use it, you slide the card in and out, and different figures show through the holes.

I have put the image above into an SVG to let you drag the card in and out on your screen by clicking and dragging. Try it out! Thanks to Peter Collingridge for the dragging code. If you would like the bare images, here is the envolope and the card.

On the reverse is a simple table which shows the area of a rectangular ceiling in various dimensions, in case you want to wallpaper your ceiling for some reason.

On the back of the inserted card is a calendar, hence my claim that this was made in 1923 or 1924.

I have not found out much about the company that made this, except for a digitized version of one of their sample catalogs.

How it works

Mostly the mechanism is fairly straightforward. The area of the sides of a room is simply

$$ 2(\text{length}+\text{width})\times\text{height}. $$

Each position of the slide corresponds to one sum, $\text{length}+\text{width}$. The table of heights just shows the corresponding sum, multiplied by the corresponding height. In fact, the sum itself shows up as well (albeit rounded up) as the "yards of border" entry in the table.

The mystery

Most of the card is quite self-explanatory. There is one thing which still perplexes me though. The calculator claims to give "exact quantities required for over 800 different sized rooms". Where did this number come from? The width is marked out from 7 to 20 giving us 14 widths, and the length is marked from 8 to 20 giving us 13 lengths. Put together with the six given heights, we get $14\times 13\times 6 = 1092$ dimensions. Wouldn't "over 1000 different sized rooms" have sounded much better? Perhaps they are being more careful than that. After all, an 8-by-10 room is no different from a 10-by-8 room, so maybe they don't want to count those twice. In that case, we would find $\binom{13}{2}+13=91$ different floor dimensions (choosing two numbers from 8 to 20, or choosing a 7 and a number from 8 to 20). Multiplying by the six heights leaves us 546, woefully short of the promised 800.

Perhaps they initially intended to make the whole thing a bit bigger, giving all the dimensions listed on the table on the back? No, this gives us the same problem. Treating length and width as separate things, we get 1122 room sizes, much larger than 800. Treating length and width as interchangeable gets us 726 room sizes, still falling short of 800.

If you have any idea where 800 comes from, let me know. I am stumped!

My proof of Descartes's theorem was just published

2022-11-30T00:00:00-05:00

Three months ago, I shared an original proof of Descartes's theorem here on my blog. Today it was finally published! It will be part of the december issue of The Mathematical Intelligencer, but you can already find it online. I made several improvements for clarity, so I consider that version to be definitive. If you don't have access though your library, you can read a preprint on ArXiV which is almost the same, just with a few more typos.

Another little puzzle

2022-11-29T00:00:00-05:00

Here is another little puzzle. Should be short. Have fun!

A simple geometry puzzle

2022-11-15T00:00:00-05:00

I found a fun puzzle last week, which I would like to share with you. It concerns the following figure.

You are given a right-angled circle sector, with a square inscribed. Beside the square another square is inscribed. The question for you is: how big are the squares? To make things easier, let's say the circle has a radius of $\sqrt{250}$. What, then, are the side lengths of the inscribed squares?

Hints

In case your geometry skills are a bit rusty, I have prepared a series of hints you may find helpful. To avoid giving it all away, I will hide them until you click the button to reveal them.

Hint 1

Hint 2

Hint 3

Hint 4

A Cubic Spline for Animation

2022-09-09T00:00:00-04:00

I am designing animations for a string of addressable LEDs. Deterministic patterns generally have a nice regularity to them, but their visual interest diminishes after a while. Random patterns can have a bit more visual interest, since they are different every time. If we just assign a random value to each pixel, the result is very busy, loud, disjointed. It would be better to have something changing in a random way, but with a smooth, regular structure so that the eye can actually take it all in.

One nice way to get a smooth, organic-feeling function is to use a polynomial spline. We can specify values to achieve at certain times (in animation these are called "key frames") and use a polynomial to interpolate between them. By choosing the spline carefully, we can get a motion which is not only continuous, but smooth in both time and space. It will have no jumps, and no times or places where the color suddenly starts changing in a different way. In this post we will walk through a procedure for generating those splines using linear algebra.

The setting

We have a one-dimensional string of LEDs. We can specify the location of each LED by a number on an interval. To make the numbers work out nice, let's put them on the interval $[0, 3]$. For symmetry, let's describe time in the same way, as an interval $[0, 3]$. For reasons which will become clear, we will focus on the time subinterval $[1, 2]$. We will put the key frames at $t=0$, $t=1$, $t=2$, and $t=3$. We will specify each key frame by the values at $s=0$, $s=1$, $s=2$, and $s=3$. That is, we begin with a function defined on $\{0, 1, 2, 3\}\times\{0, 1, 2, 3\}$, and we wish to extend it to a function on $[1, 2]\times[0, 3]$.

Why use this specific number of key values? I want to make a cubic polynomial, which we can write as $f(t, s) = \sum_{i, j=0}^3 A_{ij}t^i s^j$. This has sixteen degrees of freedom. By specifying the function at sixteen points, we can make a system which is neither over-constrained nor under-constrained.

Why go for a cubic function? I want to get a curve which is smooth in time and space. On a given interval, I want it to hit the key frames, but I also want it to be smooth at both ends. That makes four constraints, so a third degree polynomial is just right.

Why look at times between 1 and 2? I want to think of time as starting at 1, and proceeding to 2. When the time hits 2, we can extend $f$ by defining $f(t, s) = g(t-1, s)$ for $t\in\{1\}\cup[2,3]$. In this way, $g$ has the same form as $f$, with values of $g(t)$ specified for $t\in \{0, 1, 2\}$. By dropping the values of $f$ at $t=0$ and making new values for $g$ at $t=3$, the program repeats with $g$ taking the role of $f$.

The clever bit

When we restrict $f$ to $t=2$, we get a polynomial in $s$. Since it interpolates four values at $s=0, 1, 2, 3$, it is completely specified. Since $g$ restricted to $t=1$ is also a cubic interpolant, we can see that $f$ is continuous not only at $\{2\}\times \{0, 1, 2, 3\}$ but on all of $\{2\}\times [0, 3]$. If we are clever about how we specify $f$, we can do even better. Notice that $f_t$ is also a cubic polynomial in $s$ when restricted to $t=2$. If we can specify $f_t(2, s)=g_t(1, s)$ then we can make $f'$ continuous as well!

How to do this? Since $f$ is never directly evaluated at $t=3$, we will use the funciton values there to instead specify $f_t$ at $t=2$. That is, we will enforce $f_t(2, s) = (1-c) (f(3, s)-f(1, s))/2$, where $c$ is a "tension" term allowing us to tweak the behavior of the interpolant. By assigning the same rule for $g$, that is, $g_t(1, s) = (1-c)(f(3, s)-f(1, s))/2$, we get a function which is continuous and smooth.

Computing it

We began by writing $f(t, s)=\sum_{i, j=0}^3 A_{ij}t^i s^j$. We can write this as a matrix product,

$$ f(t, s) = \begin{bmatrix} 1 \\ t \\ t^2 \\ t^3 \end{bmatrix}^T A \begin{bmatrix} 1 \\ s \\ s^2 \\ s^3 \end{bmatrix}. $$

to keep things tidy, let's define $P_x = [1, x, x^2, x^3]^T$. Then we can write this as $f(t, s)=P_t^T A P_s$. The goal then is to specify the matrix $A$, in terms of the data, the key-frame values of $f$ on $\{0, 1, 2, 3\}^2$. Write $F=[f(i, j)]_{i, j=0}^3$, so we are looking for how to write $A$ in terms of $F$.

Continuity

We use the values at $t=1, 2$ to enforce the continuity of the spline. This is straightforward: we want $P_1^TAP_s = F_{1s}$ for $s=0, 1, 2, 3$. Writing $P_S = [P_0P_1P_2P_3]$ we can write this more compactly as $P_1^TAP_S = F_1$. Similarly, we want $P_2^TAP_S = F_2$. Together, these give

$$ [P_1, P_2]^T A P_S = \begin{bmatrix} 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \end{bmatrix} F. $$

Not enough to solve for $A$ yet, but we have not used smoothness yet.

Smoothness

Differentiation yields

$$ f_t(t, s) = \begin{bmatrix} 0 \\ 1 \\ 2t \\ 3t^2 \end{bmatrix}^T A \begin{bmatrix} 1 \\ s \\ s^2 \\ s^3 \end{bmatrix}. $$

Write $D_x=\frac{d}{dx} P_x$, so we can write this as $f_t = D_t^T A P_s$. We want $f(1, s) = \frac{1-c}{2}(f(2, s) - f(0, s))$. As a matrix equation, this becomes

$$ D_1^T A P_S = \frac{1-c}{2} \begin{bmatrix}-1 & 0 & 1 & 0\end{bmatrix}F. $$

Repeating for the $t=2$ case yields

$$ [D_1, D_2]^T A P_S = \frac{1-c}{2}\begin{bmatrix}-1&0&1&0\\0&-1&0&1\end{bmatrix}F. $$

Writing it this way shows how to combine with the continuity equation,

$$ [P_1, P_2, D_1, D_2]^T A P_S = \frac{1}{2}\left( \begin{bmatrix} 0 & 2 & 0 & 0\\ 0 & 0 & 2 & 0\\ -1& 0 & 1 & 0\\ 0 &-1 & 0 & 1 \end{bmatrix} +c\begin{bmatrix} 0 & 0 & 0 & 0\\ 0 & 0 & 0 & 0\\ 1 & 0 &-1 & 0\\ 0 & 1 & 0 &-1 \end{bmatrix} \right)F. $$

Solving for $A$

Now all the matrices are square, so we are in business. We have enough to solve for $A$. Writing $U=[P_1,P_2,D_1,D_2]^T$ we find

$$ U^{-1} = \begin{bmatrix}-4 & 5 & -4 & -2\\12 & -12 & 8 & 5\\-9 & 9 & -5 & -4\\2 & -2 & 1 & 1\end{bmatrix}. $$

We can also compute

$$ P_S^{-1} = \begin{bmatrix}1 & 1 & 1 & 1\\0 & 1 & 2 & 3\\0 & 1 & 4 & 9\\0 & 1 & 8 & 27\end{bmatrix}^{-1} =\frac{1}{6} \begin{bmatrix}6 & -11 & 6 & -1\\0 & 18 & -15 & 3\\0 & -9 & 12 & -3\\0 & 2 & -3 & 1\end{bmatrix}. $$

Multiplying on both sides yields

$$ A = \frac{1}{12} \left(\begin{bmatrix}4 & -6 & 6 & -2\\-8 & 19 & -16 & 5\\5 & -14 & 13 & -4\\-1 & 3 & -3 & 1\end{bmatrix} + c \begin{bmatrix}-4 & -2 & 4 & 2\\8 & 5 & -8 & -5\\-5 & -4 & 5 & 4\\1 & 1 & -1 & -1\end{bmatrix} \right) F \begin{bmatrix}-4 & 5 & -4 & -2\\12 & -12 & 8 & 5\\-9 & 9 & -5 & -4\\2 & -2 & 1 & 1\end{bmatrix}. $$

Applying the formula

Now that we have a formula for $f(t, s)=P_t^TAP_s$, we will want to apply it to our light string, which is discrete. Choose some discrete times $T = [1, 1+\Delta t, 1+2\Delta t, \dots, 2]$ and string positions $S=[0,\Delta s, 2\Delta s, ..., 3]$. Form them into polynomials $P_T$ and $P_S$ as before, then multiply them on the outside in advance; the coefficient matrices we derived above will not change, only F will change. This can save us a lot of multiplication, since much of it can be done in advance.

Conclusion

I won't belabor this any further here. You can see how this algorithm is implemented in the repository I have shared. I think this shows how linear algebra allows us to express some pretty complicated formulas quite compactly, which lets us think about more-complicated things than would otherwise be possible.

A Problem in Optimal Transport

2022-09-02T00:00:00-04:00

I like math classes. I don't like turning in math homework. Lucky for me, I am far enough along in my math education that people mostly don't assign me homework. On the other hand, solving problems is the best way anyone has found so far of learning math. I am taking a course in optimal transport theory, and so I have made some homework for myself.

In one dimension, the optimal transport problem is sometimes quite easy to solve. So long as the cost function $c(x,y)$ can be written as $\phi(|x-y|)$ where $\phi$ is convex and increasing, then there is an optimal transport plan $T$ and it is monotone, in the sense that if $x_1<x_2$ then $T(x_1)\leq T(x_2)$. Why is this? I feel we can get to the heart of it by discarding concerns about complicated distributions and sigma algebras. Let's focus on the case where we just have two point masses to move to two targets. That is, our source distribution is $\delta(x_1)+\delta(x_2)$ and the target is $\delta(y_1)+\delta(y_2)$. We will take $x_1<x_2$ and $y_1<y_2$. There are two transport plans to consider.

\begin{align*} T_\parallel&\begin{cases} x_1 \mapsto y_1 \\ x_2\mapsto y_2 \end{cases} \\ T_\perp&\begin{cases} x_1 \mapsto y_2 \\ x_2\mapsto y_1 \end{cases} \end{align*}

In a sense the plan $T_\perp$ crosses itself, while $T_\parallel$ does not. Our claim is that, given $\phi$ is convex and nondecreasing, $c(T_\parallel)\leq c(T_\perp)$. We will prove this together, paying special attention to where we use each of the conditions on $\phi$. That is, we will show that

$$ \phi(|y_1-x_1|)+\phi(|y_2-x_2|) \leq \phi(|y_1-x_2|)+\phi(|y_2-x_1|).\tag{$*$} $$

The proof

Inequality $(*)$ is symmetric in terms of $x$ and $y$, so we can take $x_1<y_1$ without loss of generality. Let's treat two cases, either $x_2>y_2$ or $x_2<y_2$.

When $x_2>y_2$

Our assumptions together tell us $x_1\leq y_1\leq y_2 \leq x_2$. Then our goal $(*)$ can be written as

$$ \phi(y_1-x_1)+\phi(x_2-y_2) \leq \phi(y_2-x_1)+\phi(x_2-y_1). $$

This case is solved by the nondecreasing assumption on $\phi$, since $\phi(y_1-x_1)\leq \phi(y_2-x_1)$ and $\phi(x_2-y_2)\leq \phi(x_2-y_1)$. We do not require convexity at all in this case.

When $x_2<y_2$

We can rewrite our goal $(*)$ as

$$ \phi(y_1-x_1)+\phi(y_2-x_2) \leq \phi(y_2-x_1) + \phi(|y_1-x_2|). $$

By repeatedly applying $x_1<x_2$ and $y_1<y_2$ we find $y_1-x_2\leq y_1-x_1\leq y_2-x_1$ and $y_1-x_2\leq y_2-x_2 \leq y_2-x_1$. By convexity, we have

\begin{align*} \phi(y_1-x_1)&\leq \frac{y_2-y_1}{y_2-y_1+x_2-x_1}\phi(y_2-x_1)+\frac{x_2-x_1}{y_2-y_1+x_2-x_1}\phi(y_1-x_2),\\ \phi(y_2-x_2)&\leq \frac{x_2-x_1}{y_2-y_1+x_2-x_1}\phi(y_2-x_1)+\frac{y_2-y_1}{y_2-y_1+x_2-x_1}\phi(y_1-x_2). \end{align*}

Adding these yields

$$ \phi(y_1-x_1)+\phi(y_2-x_2) \leq \phi(y_2-x_1) + \phi(y_1-x_2). $$

Finally, the nondecreasing assumption tells us $\phi(y_1-x_2)\leq \phi(|y_1-x_2|)$.

Conclusion

The $x_2>y_2$ case above relied only on the nondecreasing assumption. Indeed, it seems to me that it is both necessary and sufficient in that case. That's the case where both distances are reduced by changing from $T_\perp$ to $T_\parallel$. In the other case, $x_2<y_2$, we used convexity because $|x_1-T(x_1)|$ decreased while $|x_2-T(x_2)|$ increased. Convexity allows us to express the "diminishing return" property of a cost, where it's at least twice as hard to move a mass twice as far. In this case the trade was worth it, because $x_1$ had farther to go.

None of this is new stuff. Looking ahead, proposition 4.5 of Luigi Ambrosio's book treats a very similar question, from a slightly less elementary perspective. However, I do think this example is illustrative. It shows exactly what aspect of the cost function we are taking advantage of, when we use the convexity property.

An intuitive proof of the Descartes circle theorem

2022-09-01T00:00:00-04:00

I have been a little obsessed with the Descartes circle theorem for a bit over a year now, ever since I came across it when looking for fun fractals to draw. The theorem is essential for quickly computing the circles in an Apollonian gasket. As a reminder, it says that when you have four circles which are pairwise tangent, their radii satisfy

$$ \left(\frac{1}{r_1}+\frac{1}{r_2}+\frac{1}{r_3}+\frac{1}{r_4}\right)^2 = 2\left(\frac{1}{r_1^2}+\frac{1}{r_2^2}+\frac{1}{r_3^2}+\frac{1}{r_4^2}\right), $$

where the radius is taken to be negative if the corresponding circle encloses the others. This convention allows us to say $d_{12} = r_1 + r_2$ where $d_{12}$ is the distance between the centers of circles 1 and 2.

I have come up with a proof for this theorem which I like. People have been coming up with proofs of this theorem for centuries, some of them quite elaborate. The most elegant one I have found is due to Jerzy Kocik. It treats the generalized version of the theorem which was discovered in 2001, which gives a similar relation between the centers of the circles treating them as complex numbers. Kocik's proof is available on arXiv.

The following proof does not treat the generalized version of the theorem, but it does a better job of giving the intuitive reason for the theorem than any other proof I have seen. It is certainly shorter than any proof I have seen elsewhere.

Heron's formula and the Cayley-Menger determinant

Most people who have studied any geometry have at least heard of Heron's formula. There are many ways to state it. Here is one of them. It states that for any triangle with area $A$ and side lengths $a$, $b$, and $c$, we have the equation

$$ 4A^2 = (a^2+b^2+c^2)^2 - 2(a^4+b^4+c^4). $$

Perhaps this way of writing it already has stirred some inspiration in you; it certainly bears a passing resemblance to the form in the Descartes theorem. As I say, there are many ways to write Heron's formula. Here is another.

$$ -16A^2 = \begin{vmatrix} 0 & 1 & 1 & 1\\ 1 & 0 & c^2 & b^2\\ 1 & c^2 & 0 & a^2\\ 1 & b^2 & a^2 & 0 \end{vmatrix}. $$

For this proof I prefer this form because it generalizes nicely to higher dimensions. This is the Cayley-Menger determinant which gives a formula for the volume of an $n$-dimensional simplex in terms of its edge lengths. For our proof we will use the formula for the volume of the tetrahedron,

$$ 288V^2= \begin{vmatrix} 0&1&1&1&1\\ 1&0&d_{12}^{2}&d_{13}^{2}&d_{14}^{2}\\ 1&d_{21}^{2}&0&d_{23}^{2}&d_{24}^{2}\\ 1&d_{31}^{2}&d_{32}^{2}&0&d_{34}^{2}\\ 1&d_{42}^{2}&d_{42}^{2}&d_{43}^{2}&0\\ \end{vmatrix}. $$

The proof

Begin with four pairwise-tangent spheres with radii $r_1$, $r_2$, $r_3$, and $r_4$. The centers of these spheres define a tetrahedron, and the Cayley-Menger determinant formula gives us the volume of that tetrahedron in terms of $d_{ij}=r_i+r_j$. After simplification, we are left with the tidy formula

$$ V^2 = \left(\frac{r_1r_2r_3r_4}{3}\right)^2\left[\left(\frac{1}{r_1}+\frac{1}{r_2}+\frac{1}{r_3}+\frac{1}{r_4}\right)^2 -2\left(\frac{1}{r_1^2}+\frac{1}{r_2^2}+\frac{1}{r_3^2}+\frac{1}{r_4^2}\right)\right]. $$

Now we just observe that if the four centers lie in a plane, their tetrahedron must have volume zero. If all the radii are nonzero, the term $r_1r_2r_3r_4$ cannot be zero, so that leaves

$$ \left(\frac{1}{r_1}+\frac{1}{r_2}+\frac{1}{r_3}+\frac{1}{r_4}\right)^2 -2\left(\frac{1}{r_1^2}+\frac{1}{r_2^2}+\frac{1}{r_3^2}+\frac{1}{r_4^2}\right)=0 $$

and the proof is complete.

The details

I should really justify the volume formula I gave above, since it is not obvious and it is essential to the proof. It really is a "follow your nose" kind of derivation, starting with the Cayley-Menger determinant and performing straightforward simplifications. We use these common determinant simplification rules.

Adding (or subtracting) one row or column to another does not change the determinant.
Multiplying a row or column by a constant scales the determinant by that multiplicative factor.
When $D$ is invertible, the block determinant
$$\begin{vmatrix}A&B\\ C&D\end{vmatrix}$$
can be computed as $\left| D\right | \left| A - B D^{-1} C\right|$.

Since I write out the entire matrix on each line this fills a lot of space, but there are really very few steps involved. Without further ado, the algebra.

\begin{align*} 288V^2 &= \begin{vmatrix} 0&1&1&1&1\\ 1&0&d_{12}^{2}&d_{13}^{2}&d_{14}^{2}\\ 1&d_{21}^{2}&0&d_{23}^{2}&d_{24}^{2}\\ 1&d_{31}^{2}&d_{32}^{2}&0&d_{34}^{2}\\ 1&d_{42}^{2}&d_{42}^{2}&d_{43}^{2}&0\\ \end{vmatrix}\\ &= \begin{vmatrix} 0&1&1&1&1\\ 1&0&(r_1+r_2)^2&(r_1+r_3)^2&(r_1+r_4)^2\\ 1&(r_2+r_1)^2&0&(r_2+r_3)^2&(r_2+r_4)^2\\ 1&(r_3+r_1)^2&(r_3+r_2)^2&0&(r_3+r_4)^2\\ 1&(r_4+r_1)^2&(r_4+r_2)^2&(r_4+r_3)^2&0\\ \end{vmatrix}\\ \frac{288V^2}{(r_1r_2r_3r_4)^4}&= \begin{vmatrix} 0&\frac{1}{r_1^2}&\frac{1}{r_2^2}&\frac{1}{r_3^2}&\frac{1}{r_4^2}\\ \frac{1}{r_1^2}&0&(\frac{1}{r_1}+\frac{1}{r_2})^2&(\frac{1}{r_1}+\frac{1}{r_3})^2&(\frac{1}{r_1}+\frac{1}{r_4})^2\\ \frac{1}{r_2^2}&(\frac{1}{r_2}+\frac{1}{r_1})^2&0&(\frac{1}{r_2}+\frac{1}{r_3})^2&(\frac{1}{r_2}+\frac{1}{r_4})^2\\ \frac{1}{r_3^2}&(\frac{1}{r_3}+\frac{1}{r_1})^2&(\frac{1}{r_3}+\frac{1}{r_2})^2&0&(\frac{1}{r_3}+\frac{1}{r_4})^2\\ \frac{1}{r_4^2}&(\frac{1}{r_4}+\frac{1}{r_1})^2&(\frac{1}{r_4}+\frac{1}{r_2})^2&(\frac{1}{r_4}+\frac{1}{r_3})^2&0\\ \end{vmatrix}\\ &= \begin{vmatrix} 0&\frac{1}{r_1^2}&\frac{1}{r_2^2}&\frac{1}{r_3^2}&\frac{1}{r_4^2}\\ \frac{1}{r_1^2}&0&\frac{1}{r_1^2}+\frac{2}{r_1r_2}+\frac{1}{r_2^2}&\frac{1}{r_1^2}+\frac{2}{r_1r_3}+\frac{1}{r_3^2}&\frac{1}{r_1^2}+\frac{2}{r_1r_4}+\frac{1}{r_4^2}\\ \frac{1}{r_2^2}&\frac{1}{r_2^2}+\frac{2}{r_2r_1}+\frac{1}{r_1^2}&0&\frac{1}{r_2^2}+\frac{2}{r_2r_3}+\frac{1}{r_3^2}&\frac{1}{r_2^2}+\frac{2}{r_2r_4}+\frac{1}{r_4^2}\\ \frac{1}{r_3^2}&\frac{1}{r_3^2}+\frac{2}{r_3r_1}+\frac{1}{r_1^2}&\frac{1}{r_3^2}+\frac{2}{r_3r_2}+\frac{1}{r_2^2}&0&\frac{1}{r_3^2}+\frac{2}{r_3r_4}+\frac{1}{r_4^2}\\ \frac{1}{r_4^2}&\frac{1}{r_4^2}+\frac{2}{r_4r_1}+\frac{1}{r_1^2}&\frac{1}{r_4^2}+\frac{2}{r_4r_2}+\frac{1}{r_2^2}&\frac{1}{r_4^2}+\frac{2}{r_4r_3}+\frac{1}{r_3^2}&0\\ \end{vmatrix}\\ &= \begin{vmatrix} 0&\frac{1}{r_1^2}&\frac{1}{r_2^2}&\frac{1}{r_3^2}&\frac{1}{r_4^2}\\ \frac{1}{r_1^2}&\frac{-2}{r_1^2}&\frac{2}{r_1r_2}&\frac{2}{r_1r_3}&\frac{2}{r_1r_4}\\ \frac{1}{r_2^2}&\frac{2}{r_2r_1}&\frac{-2}{r_2^2}&\frac{2}{r_2r_3}&\frac{2}{r_2r_4}\\ \frac{1}{r_3^2}&\frac{2}{r_3r_1}&\frac{2}{r_3r_2}&\frac{-2}{r_3^2}&\frac{2}{r_3r_4}\\ \frac{1}{r_4^2}&\frac{2}{r_4r_1}&\frac{2}{r_4r_2}&\frac{2}{r_4r_3}&\frac{-2}{r_4^2}\\ \end{vmatrix}\\ \frac{288V^2}{(r_1r_2r_3r_4)^2}&= \begin{vmatrix} 0&\frac{1}{r_1}&\frac{1}{r_2}&\frac{1}{r_3}&\frac{1}{r_4}\\ \frac{1}{r_1}&-2&2&2&2\\ \frac{1}{r_2}&2&-2&2&2\\ \frac{1}{r_3}&2&2&-2&2\\ \frac{1}{r_4}&2&2&2&-2 \end{vmatrix}\\ \frac{288V^2}{8(r_1r_2r_3r_4)^2}&= \begin{vmatrix} 0&\frac{1}{r_1}&\frac{1}{r_2}&\frac{1}{r_3}&\frac{1}{r_4}\\ \frac{1}{r_1}&-1&1&1&1\\ \frac{1}{r_2}&1&-1&1&1\\ \frac{1}{r_3}&1&1&-1&1\\ \frac{1}{r_4}&1&1&1&-1 \end{vmatrix}\\ &=-\begin{vmatrix} -1&1&1&1\\ 1&-1&1&1\\ 1&1&-1&1\\ 1&1&1&-1 \end{vmatrix} \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix}^T \begin{bmatrix} -1&1&1&1\\ 1&-1&1&1\\ 1&1&-1&1\\ 1&1&1&-1 \end{bmatrix}^{-1} \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix} \end{align*}

Notice the matrix

$$ D=\begin{bmatrix} -1&1&1&1\\ 1&-1&1&1\\ 1&1&-1&1\\ 1&1&1&-1 \end{bmatrix} $$

satisfies $D^2=4I$. Thus, $D^{-1} = \frac{1}{4}D$. We can also compute $|D| = -16$. Just a couple more lines and we are done with the algebra.

\begin{align*} \frac{288V^2}{32(r_1r_2r_3r_4)^2} &= \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix}^T \begin{bmatrix} -1&1&1&1\\ 1&-1&1&1\\ 1&1&-1&1\\ 1&1&1&-1 \end{bmatrix} \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix}\\ \frac{9V^2}{(r_1r_2r_3r_4)^2} &= \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix}^T \begin{bmatrix} 1&1&1&1\\ 1&1&1&1\\ 1&1&1&1\\ 1&1&1&1 \end{bmatrix} \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix} -2\begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix}^T \begin{bmatrix} 1&0&0&0\\ 0&1&0&0\\ 0&0&1&0\\ 0&0&0&1 \end{bmatrix} \begin{bmatrix} 1/r_1 \\ 1/r_2 \\ 1/r_3 \\ 1/r_4 \end{bmatrix}\\ &=\left(\frac{1}{r_1}+\frac{1}{r_2}+\frac{1}{r_3}+\frac{1}{r_4}\right)^2 -2\left(\frac{1}{r_1^2}+\frac{1}{r_2^2}+\frac{1}{r_3^2}+\frac{1}{r_4^2}\right) \end{align*}

Return to Battleship

2022-08-28T00:00:00-04:00

Particularly in grad school it can feel like your life is standing still. Because you are always learning new things, pushing yourself outside of your comfort zone, it can seem like you have not mastered anything. This is an illusion. To prove this, all you need to do is look at something you made before and feel the cringe. If you cringe at the way you solved a problem before, that is a sure sign that you know better now than you did then.

I am in the midst of refreshing my math department webpage, removing what is out-of-date and preserving what deserves to be preserved. Four years ago, I was teaching myself Javascript. I was also frequently playing Battleship over the phone with my then-girlfriend, now-wife. I made a quick tool to generate ship placements for me. Last year I heard from an old friend that they had actually found the tool on a search, and that it had been useful. For that reason, I think it's worth preserving. I have copied it below.

I know better than to jump back in to a completed project. The tool I made works, and it works well. To redo it would be a wasted effort. However, the power of cringe is strong. I feel compelled to at least comment on the bad parts of the code, if only to reassure myself that I have indeed grown.

The tool

This is a placement generator for Battleship. It will give you a randomly selected arrangement of your ships on the board. Here, "randomly selected" means that every possible arrangement is equally likely.

Written by Alden Bradford on November 1-2, 2018. Generated placements are guaranteed to be (pseudo) random, but not guaranteed to be good. Use at your own risk.

The good

One of the things which makes this particular tool so useful is that it is written in pure Javascript. Everyone with a modern web browser has a Javascript interpreter already installed and ready to go. The code is so portable that I was able to copy it directly here with no changes, and it still works perfectly. This is why I think Javascript is a good first language for many people to learn. There are exceptions, of course -- if you want to do data science you should learn Python, if you want to program Arduino you should learn C, et cetera. For most people, the benefit of having your code run anywhere outweighs the cost of having to deal with Javascript's peculiarities. Perhaps this will change soon, as there are several attempts in the works to make Python available in the browser. For now, Javascript has a strong advantage.

Let's have a look at my old code and see what nice qualities it has, lest we become overcritical.

"use strict";

var theForm = document.getElementById("input_form");

function generateBoard(){
    let board = new Board(theForm);
    let container = document.getElementById("the_board");
    board.placeShips();
    if (!board.failed){
        container.innerHTML = board.appearance();
    } else {
        container.innerHTML = "I tried 1,000,000 times, but \nI could not make the board work.";
    }   
}

function parseShips(string){
    let inputList = string.match(/\w,\d+/g);
    let ships = [];
    for(let i = 0; i < inputList.length; i++){
        let pair = [];
        pair[0] = inputList[i].match(/\w/)[0];
        pair[1] = parseInt(inputList[i].match(/\d+/)[0],10);
        ships[i] = pair;
    }
    return ships;
}

class Board {
    constructor(form){
        this.rows = form.elements.rows.valueAsNumber;
        this.cols = form.elements.columns.valueAsNumber;
        this.cells = [];
        this.initializeCells();
        this.shipPairs = parseShips(form.elements.ships.value);
        this.failed = false;
    }
    initializeCells(){
        this.cells = [];
        for(let i=0;i<this.cols;i++){
            this.cells[i]=[];
            for(let j=0;j<this.rows;j++){
                this.cells[i][j]= new Cell();
            }
        }
    }
    appearance(){
        let string = 
        "   A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z ";
        string = string.slice(0,this.cols*2+2);
        string = string.concat('\n');
        for(let j = 0; j < this.rows; j++){
            if( j < 9)  string = string.concat(' ');
            string = string.concat(`${j+1}`);
            for(let i = 0; i < this.cols; i++){
                string = string.concat(" "+this.cells[i][j].appearance());
            }
            string = string.concat('\n');
        }
        string = string.slice(0,-1);
        return string;
    }
    placeShip(charLenPair){
        let direction = ["v","h"][Math.floor(Math.random()*2)];
        let max_col = this.cols;
        let max_row = this.rows;
        if(direction === "v") max_row -= (charLenPair[1]-1);
        if(direction === "h") max_col -= (charLenPair[1]-1);
        if(max_row <1 || max_col<1) return false;
        let corner=[Math.floor(Math.random()*max_col),
                    Math.floor(Math.random()*max_row)];
        let newShip = new Ship(charLenPair,direction,corner,this);
        if(newShip.canFit()){
            newShip.insert();
            return true;
        } else {
        return false;
        }
    }
    placeShips(){
        for(let attempt = 0; attempt < 1000000; attempt++){
            this.initializeCells();
            let attemptSuccessful = true;
            for(let i = 0; i<this.shipPairs.length; i++){
                if(!this.placeShip(this.shipPairs[i])){
                    attemptSuccessful = false;
                    break;
                }
            }
            if(attemptSuccessful){
                return;
            }
        }
        this.failed = true;
    }
}

class Ship{
    constructor(charLenPair,orientation,corner,board){
        this.appearance = charLenPair[0];
        this.length = charLenPair[1];
        this.orientation = orientation;
        this.corner = corner;
        this.board = board;
    }
    cells(){
        let cellList = [];
        if(this.orientation === "h"){
            for(let i = 0; i < this.length; i++){
                cellList[i] = this.board.cells[this.corner[0]+i][this.corner[1]  ];
            }
        }
        if(this.orientation === "v"){
            for(let i = 0; i < this.length; i++){
                cellList[i] = this.board.cells[this.corner[0]  ][this.corner[1]+i];
            }
        }
        return cellList;
    }
    canFit(){
        let cellList = this.cells();
        for(let i = 0; i<this.length; i++){
            if(cellList[i].contains) return false;
        }
        return true;
    }
    insert(){
        let cellList=this.cells();
        for(let i = 0; i<this.length; i++){
            cellList[i].contains = this;
        }   
    }
}

class Cell {
    constructor(){
    this.contains = null;
    }
    appearance(){
        return this.contains ? this.contains.appearance : '~';
    }
}

I like the functional and object-oriented qualities of this program. It makes sense to have a class for the game board and the ships, since there is a natural flow of these units going back and forth, asking each other questions. The game board is only generated in one spot, and a new object is made every time a board is generated. That makes it simple to follow the flow of the program and predict its state.

The bad

This is all done as an inline script. That's not too unwieldy for a script of this size, but it is still not the way I would do it now. For one thing, it could lead to problems down the line if the program were to grow. For another, we are filling up the global namespace. This one is not too bad due to its size, only creating 6 global objects. Still, we could get it down to none by making this its own separate module.

While I like the object-oriented style, I do not like the use of Javascript classes here. For new projects I have adopted the "class free" style I learned from Douglas Crockford's book. Essentially, we can avoid ever having to deal with this and all its oddities by avoiding the class syntax all together. There is some memory overhead in going class-free, since objects no longer share references to their methods, instead each storing their own methods. In practice this is not really a problem since we seldom have many instances of a class to begin with.

This brings me to a more fundamental problem with the code above. What's that class Cell supposed to be doing? All it does is store a reference to an object which is either null or a character. I suspect that in a previous version of the code I had the cell doing more work, keeping track of its neighbors or some such. With the wisdom of more years, I can see that the class should never have been made at all. I should have used the built-in strings instead.

The janky

I don't wish to pick nits over strange formatting or missing semicolons. I won't harp on the liberal use of let where const would be more appropriate. Instead I will conclude by pointing out a few "What was I thinking?" absurdities.

Why oh why is there something called a charLenPair floating around? That should plainly just be an object, so that you can refer to the character or length as you see fit.

Why is there a function called generateBoard that lives outside the class Board? Surely this is the constructor for the class, and it should live within the class. I think I can tell what I though all those years ago, that I should separate those bits of code which interact with the DOM from those which keep to themselves. That's a good instinct, but it seems to have led to an absurd result in this case.

Why does the ship parser ignore parentheses? Why does it process each string three times, with three separate regular expressions? All of these can be explained by the fact that I was not experienced with regular expressions back then. That whole function feels wrong now, as a better-made regular expression would be more explicit and fail in more obvious ways.

Why do I left pad the digits in Board.appearance by checking if they are less than 9? That's much harder to read than String.padStart, for example. Of course, String.padStart was only introduced in 2017 after the famous left-pad scandal, so I may well not have heard of it yet at the time.

Conclusion

Even though I can see many ways to improve it, this is ultimately a good piece of code. It does what it set out to do, and works just about anywhere.

It would be easy for me to hide my previous blunders, hastily rewrite the code here to be up to my current standards. I believe that would be a mistake. We should wear our early attempts with pride and learn from them where we can. This keeps us humble, and I hope it is instructive to those who are just beginning. It's okay to make mistakes, it's okay to do things in a poorly-thought-out way. It's better to make the mistakes and learn from them than to be paralyzed in unending revisions.

Decoding a multiplexed LCD

2022-08-12T00:00:00-04:00

The button-pressing side of Xanthippe is currently working intermittently. I have ordered some more-appropriate parts which will hopefully improve matters. In the mean time, the LCD decoding functionality is working fine. Now is an ideal time to figure out the correspondence between the signals heading to the display and the segments which are activated.

Previously, when designing the display for my calculator emulator, I painstakingly traced every segment. I found that there are precisely 112 segments. There are 32 wires going into the LCD, making up 4 ground planes and 28 data lines, for a total of 4x28=112 segments. It's clear there is an alignment between the two, it's just a matter of figuring it out.

Naming conventions

In order to describe the correspondence, it will be necessary to have names for the signals and names for the segments. I already have names I like for the segments, which I made up when creating this SVG file.

I have edited the file here to overlay some of the segment labels. Each digit is numbered starting from the right at 0. Each segment within follows a traditional lettering scheme for 7 segment displays. For the orphan "-" sign at the left, it is numbered as though there were an entire digit around it. The exponent digits are numbered similarly, prefixed with E. The indicators above are text, so their labels are simply their text content.

When naming the signals I wish to refer back to the physical device as much as possible. I have numbered the wires leading to the display, starting with 1 closest to the battery. The first four wires carry the ground planes. I have also assigned each ground plane a letter, according to the order the segments cycle through when displaying. They repeat a pattern of 4-3-2-1, so I have assigned the backplane on pin 4 the letter A, the plane on pin 3 the letter B, and the plane on pin 2 the letter C.

I have put together a simple script which constantly polls the screen and produces the following output.

   33322222222221111111111000000000
   21098765432109876543210987654321
A: ......##....................#...
B: #.....##.....................#..
C: #.....#.......................#.
D: ......##.......................#

A "." indicates that the corresponding segment is not active, and "#" indicates it is active. In this way we end up with a table. All that remains is to fill it in with labels.

The table

To avoid filling the whole screen with tables, I will include the full table here only once. Below I will describe how it was filled in.

	32	31	30	29	28	27	26	25	24	23	22	21	20	19	18	17
A	STAT	R	K	E0D	()	E1D	0DP	0D	1DP	1D	2DP	2D	3DP	3D	4DP	4D
B	DE	X	E0C	E0E	E1C	E1E	0C	0E	1C	1E	2C	2E	3C	3E	4C	4E
C	G	RAD	E0B	E0G	E1B	E1G	0B	0G	1B	1G	2B	2G	3B	3G	4B	4G
D	FIX	E2G	E0A	E0F	E1A	E1F	0A	0F	1A	1F	2A	2F	3A	3F	4A	4F

	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1
A	5DP	5D	6DP	6D	7DP	7D	8DP	8D	9DP	9D	M3	2nd	A	.	.	.
B	5C	5E	6C	6E	7C	7E	8C	8E	9C	9E	10G	HYP	.	B	.	.
C	5B	5G	6B	6G	7B	7G	8B	8G	9B	9G	M2	ENG	.	.	C	.
D	5A	5F	6A	6F	7A	7F	8A	8F	9A	9F	M1	SCI	.	.	.	D

The backplanes

These are free spaces. Bingo!

DEGRAD

The angle indication is actually composed of three segments, "DE", "G", and "RAD". By cycling through the angle modes, we can infer the values from each combination.

Indicators

Most of the indicators can be toggled on or off individually. That saves us some effort, we can just inspect them one at a time.

Digits

What about the digits? The calculator powers on showing "0.", which indicates that most of the first digit lies in columns 25 and 26. If we enter "8." this confirms it, and tells us segment G for free.

Pushing the digit to the left by hitting zero, we find columns for the other digits just the same. Hitting "-" at the end tells us 10G.

Now we must discern which segment is which. I don't like to assume, so let's test all of them. Starting with "G", since we can just push a negative sign through to see it. We can get DP by sending and 8 along without its decimal point. Next grab E by sending a 9 along. 6 gives us B in a similar way. Take away F from 9 and you get 3, so 3 will tell us F. 1 consists of B and C, and we know B, so 1 gives us C. Finally, 7 is the only digit which distinguishes between A and D, so we need it to get us those. Now we are done with the mantissa

Exponent

A bit trickier since you can't have a blank digit in the exponent. We can have 8, the complement of blank. By comparing everything against 8, we get all our segments in the same way.

Conclusions

We can see a definite pattern, with the digits all using the same configuration of segments on backplanes, just placed on different pins.We can see that the "K" and "()" indicators are filling the spots of the exponent's decimal points.

We can also see that a natural way to encode this signal would be to group adjacent pairs of wires into bytes, so that one digit with associated decimal point ends up occupying exactly one byte.

Now that I have confidence in the wiring of the LCD reader, all that remains is to get a stable solution to the button pressing problem. I have some ideas for how this will get done, but this will make up a future post. Stay tuned!

Lessons from the Xanthippe circuit board

2022-08-11T00:00:00-04:00

It is too bad! Always the old story! When a man has finished building his house, he finds that he has learnt unawares something which he OUGHT absolutely to have known before he began to build. The eternal, fatal "Too late!" The melancholia of everything COMPLETED—!

-- Friedrich Nietsche, Beyond Good and Evil, section 277, translated by Helen Zimmern

It's here! The board I designed has arrived!

This is always an exciting time. Marvel over all the little details which went into a circuit board, which seemed so much larger on the computer screen. Patiently solder all the connections. Curse the clever choices you made only a week prior. Hold your breath to see if it works as you hoped.

We are always our own harshest critics. I have been often told not to point out the flaws of my own artistic works -- most people won't notice the flaws unless pointed out, and many wouldn't consider them flaws unless they are told. There is wisdom in that. We should embrace the imperfect, recognizing that we are also imperfect.

We should also be frank with ourselves. We can embrace the mistakes we made while simultaneously taking measures to prevent those mistakes in the future. This blog is mostly just for my own reference. With that in mind, this blog post lists some lessons which I hope will stick with me.

Board size

The board manufacturer I used, JLCPCB, provides a significant discount for boards which fit within a 100X100mm square. I think I could have fit my design into this space if I had set out to do so from the beginning. Once I realized this, though, I had already done most of the fiddly layout and didn't want to change it.

Also, I had initially neglected to include mounting holes in my design. I put some in by expanding the outline, which led to large mostly-unused margins at the top and bottom. If I had included mounting holes from the beginning, I would have saved some space over all.

Default behavior

Some of the chips in my circuit, notably the 74HC595 chips, have undefined behavior if their inputs are not driven. This is no good if the board receives power before the microcontroller is driving it. This could have been avoided by using some pulldown resistors on all the inputs.

Resistor arrays

I got pretty bored soldering the 32 pullup resistors individually. It was much more pleasant than doing the same on prototype board, but still not great. I think I would happily accept the additional expense of using resistor arrays for pullups, since this almost halves the number of solder points and means dealing with larger (i.e. less fiddly) parts.

TO-92 footprints

These gave me a lot of trouble during soldering. I used a footprint for standard, unbent leads. That made it easy to insert the parts, sure, but it meant the pads were too close for easy soldering. This led to a few solder bridges I had to fix. Next time I will definitely go for a bent-lead footprint, just to make the hand soldering easier.

Breakouts

Now that I am powering up and debugging the circuit, it would be quite useful to have a header for each of the signals for testing. Even something as simple as duplicating the input/output headers, so I can access them while they are plugged. That would have been a cheap thing to add, which would make the current task easier.

Disconnects

Since there is more than one part to the circuit, it would be a help to the debugging if I could isolate parts of the circuit from one another. I'm thinking something like a double row of headers, which I could join with jumpers. That would also help if I decide to keep half the circuit but replace the other half -- I could just leave some of the jumpers off to disconnect the portion I don't need, and even use the headers to move the signal to another board.

Conclusion

I am in the midst of hunting down bugs and errors, finding out why the circuit does not do exactly what I want it to. It is easy then to forget all the things it is doing well. Aside from the trouble with the TO-92 footprints, the board was quite easy to assemble. The layout is fairly sensible, and by not packing parts too tight I was able to get the soldering iron everywhere it needed to go. It is a good design, even if it is not working right just yet. The goal of pointing out the errors that were made is not to diminish the usefulness of the board I have, or the work that went into it. Rather, I hope to make the next board I make even better.

Revisiting Apollonian gaskets

2022-08-06T00:00:00-04:00

Last summer I designed Apollo, a tool for making Apollonian gaskets. Now I am a year older and a year wiser, so I think it's worth revisiting it. There are a few great improvements we can make, particularly when it comes to making integral packings, i.e. packings where the bend of every circle is an integer.

Computing bends to start from

No primitive bends

There are basically two places where the code can be improved. First, the algorithm I use to find the primitive bends for a packing could be better. In particular, there are cases where it gets into an infinite loop, due to the gasket being in fact unbounded. The algorithm I use starts with three bends and finds a fourth using the quadratic formula. Then, by placing the bends in increasing order and using the mapping

$$ (w, x, y, z) \mapsto (w, x, y, 2(w+x+y)-z) $$

we make the largest bend smaller. If this makes the largest bend bigger instead, we are done, we found the primitive bends. Otherwise we sort the bends to find the new largest bend and repeat.

The problem with this strategy is that for some gaskets, the bend can decrease indefinitely toward zero without going negative. In those cases this strategy will not terminate. Here is an example. To make things simple, let's take $w=0$, and take the other bends to be in a geometric progression $(x, y, z) = (x, \alpha x, \alpha^2 x)$. By Descartes's theorem, $\alpha$ must satisfy the equation

$$ 2(1+\alpha^2+\alpha^4) = (1+\alpha+\alpha^2)^2. $$

At first this may look nasty, but it gets nicer if we do a backwards sort of completing the square, I suppose you could say completing the difference-of-squares.

\begin{align*} \alpha^4+\alpha^2+1 &= (\alpha^4+2\alpha^2+1)-\alpha^2\\ &= (\alpha^2+1)^2-\alpha^2\\ &= (\alpha^2+\alpha+1)(\alpha^2-\alpha+1) \end{align*}

So, we see a common factor in both sides of the equation. We can factor it out as

$$ (\alpha^2+\alpha+1)(\alpha^2-3\alpha+1)=0. $$

This has two real roots, the solutions to $\alpha^2-3\alpha+1=0$. For our purposes I prefer to write this as $\alpha+\frac{1}{\alpha} = 3$, which emphasizes that the two solutions are reciprocal to one another. Taking $\alpha$ to be the larger of these two roots ($\alpha=(3+\sqrt{5})/2$ if you are curious) puts our original bends in increasing order.

If we apply our mirroring strategy to $(0, x, \alpha x, \alpha^2 x)$ we get rid of $\alpha^2 x$ and replace it with

\begin{align*} 2(x+\alpha x)-\alpha^2 x &= 2x+2\alpha x -(3\alpha-1) x\\ &= (3-\alpha) x\\ &= \frac{1}{\alpha} x. \end{align*}

Sorting the bends gives us $(0, \frac{1}{\alpha} x, x, \alpha x)$. We see that for this configuration of bends the mirroring lets the bends decrease indefinitely toward zero, dividing their magnitudes by $\alpha$ at each stage.

This can never happen if the first four bends are integers since no sequence of positive integers can decrease forever. The method specified above fails precisely because some of the time we don't get integer bends. A better solution would be to treat the cases separately, i.e. figure out a plan to deal with large regions and just plot any three bends specified, without first reducing the bends.

A list of good bends

The reason I previously included the bend-reducing algorithm was as a way to generate integral gaskets. Usually, if I care about the exact bend of a gasket, it's because it's an integral packing. Why not simply provide a list of all the integral packings?

In this paper from 2003 the authors provide a way of describing all the primitive integral packings in their theorem 4.1. They give a one-to-one correspondence between primitive packings of the form $(a, b, c, d)$ and integer solutions to the equation $x^2+m^2=d_1d_2$ satisfying $x<0\leq 2m\leq d_1 \leq d_2$ and $\gcd(x, d_1, d_2)=1$.

\begin{align*} a&=x\\ b&=d_1-x\\ c&=d_2-x\\ d&=-2m+d_1+d_2-x \end{align*}

I want these grouped by their outer bend, so I will fix $a=x=-n$. As it turns out, for each fixed $n$ there are not too many candidates for $m$, and we can check them all provided $n$ isn't too big.

Since we want $2m\leq d_1$ and $2m\leq d_2$ it follows that $4m^2\leq d_1d_2$ and so $3m^2\leq d_1d_2-m^2=n^2$. Thus, we only need to check $m<n/\sqrt{3}$. For each $m$, we can just try all the numbers $d_1$ between $2m$ and $\sqrt{n^2+m^2}$ to see if they divide $n^2+m^2$. If so that gives us $d_2$, so we can just check if $\gcd(n, d1, d2)=1$. Here's some Python code to carry out this procedure.

import math


def get_primitive_bends(n):
    if n == 0:
        yield 0, 0, 1, 1
        return
    for m in range(math.ceil(n / math.sqrt(3))):
        s = m**2 + n**2
        for d1 in range(max(2 * m, 1), math.floor(math.sqrt(s)) + 1):
            d2, remainder = divmod(s, d1)
            if remainder == 0 and math.gcd(n, d1, d2) == 1:
                yield -n, d1 + n, d2 + n, d1 + d2 + n - 2 * m


for n in range(10):
    for bend in get_primitive_bends(n):
        print(bend)

This gives us exactly the list on Wikipedia.

(0, 0, 1, 1)
(-1, 2, 2, 3)
(-2, 3, 6, 7)
(-3, 4, 12, 13)
(-3, 5, 8, 8)
(-4, 5, 20, 21)
(-4, 8, 9, 9)
(-5, 6, 30, 31)
(-5, 7, 18, 18)
(-6, 7, 42, 43)
(-6, 10, 15, 19)
(-6, 11, 14, 15)
(-7, 8, 56, 57)
(-7, 9, 32, 32)
(-7, 12, 17, 20)
(-8, 9, 72, 73)
(-8, 13, 21, 24)
(-8, 12, 25, 25)
(-9, 10, 90, 91)
(-9, 11, 50, 50)
(-9, 14, 26, 27)
(-9, 18, 19, 22)

We could certainly get more clever about how we find $d_1$ and $d_2$, though trial division works well for small $n$. An example speedup is to notice $d_1d_2=m^2+n^2$ is the sum of two squares. By the aptly-named sum of two squares theorem, we know any prime factors of $m^2+n^2$ which are congruent to $3$ mod $4$ must have an even exponent -- for example, if $m^2+n^2$ is divisible by $7$ then it must also be divisible by $49$. We can use that to find the factorization quicker, possibly requiring many fewer trial divisions.

Using integral bend-centers

In this other article, the authors show that every integral packing can be translated and rotated to make it strongly integral, i.e. with integer bend-centers. They do this by embedding every integral packing into a single integral superpacking, and rotating/translating that integral superpacking to get a strongly integral superpacking.

The benefits of having integer bend-centers should be obvious. Not only is it generally faster to do arithmetic on integers, we also no longer have to worry about floating point errors creeping in as we delve deeper. We could use this to make an interactive tool which lets you zoom in as far as you like, without fear of drifting off course.

In that paper they do not give an algorithm explicitly for constructing a strongly integral packing for a given integral packing. However, we can adapt a couple of their theorems to create a strategy. That's what I'll describe here.

Their theorem 4.2 is proved by creating a superapollonian group action which takes a given Descartes configuration to $(0, 0, g, g)$. If we start with a primitive configuration, then we can take $g=1$. What we will do is apply their proposed strategy, saving the group action -- specifically, its representation as a 4x4 orthogonal matrix. Taking the transpose gives us the inverse action.

We can then apply that action to a strongly integral packing of $(0, 0, 1, 1)$. For example, if we apply it to

$$ \begin{bmatrix} 0 & 0 & 1\\ 0 & 0 &-1\\ 1 & 1 & 0\\ 1 &-1 & 0 \end{bmatrix} $$

then we will get the embedding of our desired configuration of bends in the standard strongly integral superpacking. What's more, the location in the plane will be aligned with the superpacking -- we can trivially shift it back to the origin for plotting if we wish, or we can make a neat drawing of the whole superpacking with the desired circle indicated.

Where this will go

I don't personally have too much interest in making more drawings of gaskets. The ones I made are pretty enough, and Apollo does well enough at creating them. I might patch it to use the list of gaskets above. If I do make a new version, I think I would want it to be a tool for exploring the Superapollonian packing. Something where you can scroll through in real time, or pinch to zoom on a touchscreen. Have a side panel to highlight specific integral packings.

Introducing Xanthippe

2022-08-04T00:00:00-04:00

I have been going on about my project to emulate a calculator in the browser for some time. A month or so ago I decided that, if I am going to make the more fiddly bits of the calculator work correctly, I should really find a way to generate tests automatically.

I have spoken previously about how an emulator is really the ideal venue for test-driven development. All the visible behaviors of the finished product are completely specified, in the sense that any feature not-yet-implemented corresponds to a class of inputs which produce an incorrect output. If you want to know what the emulator should do in a given situation, all you have to do is check against the real deal.

Up to now, I have been using a suite of tests I carefully chose based on pressing buttons by hand. That made sense when there were only a dozen or two tests. Because the examples are carefully chosen, I don't necessarily need many tests to cover a wide range of features. Now there are close to 50 tests, and the remaining functionality -- fractions, statistics registers, base 10 encoding, alternative display styles -- rely on hidden information. With more state involved, I expect the number of necessary test to explode.

What is Xanthippe?

This is where Xanthippe comes in. Instead of pressing the buttons myself and documenting what the display shows, I will program a computer to press the buttons for me. This way all I have to do is specify a string of presses, and I can automatically get what the calculator shows at each stage. This way I can really "go ham" designing the emulator, and have real confidence that the emulator behaves like the genuine article.

I have already soldered test points to a calculator and figured out the electrical characteristics of the buttons and the display. I have designed a circuit board which reads the signals from the LCD to a shift register and writes button presses from a shift register. Assuming the circuit works as intended (the circuit board is still in the mail right now) I should be able to write code for any microcontroller which controls the calculator and reads its outputs.

Currently, my dream for Xanthippe is that it will be an art piece hanging on a wall in a glass box, constantly pressing buttons on the calculator and recording the results. It will send all the results onto Github, so I can test my emulator against them whenever I make a change. I also want to be able to make requests for specific sequences to check, so I can still design test cases explicitly.

Why the name?

I am emulating the TI-30Xa, and there are not too many names which start with the letters "Xa". I think Xavier would be a better name for the emulator itself (easier to type). Xanthippe is the name of the wife of Socrates. I think that's somewhat fitting, for a character who sits behind the scenes and makes sure the famous one is keeping in line. Xanthippe is often portrayed as stubborn and unyielding, which fits the role of a testing suite. Though the emulator may disagree, we will know Xanthippe is right.

What cases to test?

Once I have Xanthippe pushing buttons, the obvious question to ask is "which ones?". There are 40 buttons, and button press sequences often reach over 20 presses in length, so there is no hope of just trying every combination. Many of those combinations will reach an error state long before they reach the end, and calculator does not do much upon reaching an error state, so in reality we can cut lots of sequences short. There are still well too many for an exhaustive search.

A few combinations spring to mind as obvious additions. First, I have already specified many button sequences as good tests, may as well do those. Second, since my emulator runs in the browser, it is not too tricky to ask it to phone home. Whenever someone completes a session with the emulator I can have it send off the button presses, and Xanthippe can check them. That way I am sure to have coverage of the cases people actually use, at least the second time they try it. I could even do something silly like loading answers from Xanthippe when I have them instead of using the emulator, which could make people think I am very fast at fixing bugs. Probably unwise since that would lead to inconsistent behavior, which is the only thing harder to troubleshoot than incorrect behavior.

Another way I can choose button presses is to explore the area around existing sequences. For example, if there is something in memory, I could press buttons to read what it is. I could subtract the visible part of a mantissa to reveal the hidden part. This surely deserves its own blog post.

How to save the answers?

The calculator does not give us a whole lot of information. Most of the computation happens within the epoxy blob, a "black box" as it were. Really, I just need a way of mapping each sequence of button presses to a display on the screen. Since there are 40 buttons a button press can fit in a single byte. There are 118=8x14 segments on the screen. Not all the combinations are possible of course, so I could fit the LCD into less than 14 bytes, but why bother? The premise of Xanthippe is that I don't know everything the calculator does at all times, so I may as well have a format which can store every result conceivable. This also will take less processing, since what I get from the screen are raw bits.

There is actually one more thing I can measure, which I may as well do. The calculator takes longer to process some presses than others. I have to monitor how long it takes to respond anyhow, since I can't give a new button press while I am waiting for the previous one to resolve. Why not record the time each button press takes? In some future version of the emulator I may wish to simulate the actual delay the calculator gives, so I may as well record that as well. That way I actually have every piece of information the calculator will give me.

I can be somewhat clever about the data structure I use. After each button press, the calculator gives me a result to store. However, multiple sequences of button presses can start with the same few buttons. Why repeat them in the storage? I can instead do a tree structure. In JSON, one node of the tree might look something like this.

{
    "display": "dQw4w9WgXcQ",
    "time": 148,
    "a":{}
    "X":{}
    "7":{}
}

Here dQw4w9WgXcQ is an example base-64-encoded LCD reading. Time is how long the button press took, in some appropriate units. Each of those single-character keys would be a button press, and it would lead to a child node of the same type. We would only include those children which we have evaluated. A tree is a simple, sensible way to store the type of data we are creating.

How to encode the keys?

The shift register in hardware which receives the key presses takes two bytes, switching 16 transistors. The most naive way of storing the presses would be to just record the two bytes which are sent.

That is quite wasteful, since far from every combination of transistors would ever be turned on. We know there are 40 buttons, and the next power of two up from there is 64=2^6. We should be able to store one button press in less than one byte, rather in one base-64 character.

You may recall this table from a previous post.

	A0	A1	A2	A3	A4	A5	A6	A7
B0	+/-	2nd	+	0	.	SIN	1/x
B1	y^x	HYP	-	1	5	COS	x^2
B2	OFF	pi	X	2	6	TAN	sqrt
B3		Sigma+	/	3	7	DRG	EE
B4		STO	=	4	8	LOG	(
B5		RCL	ab/c	<-	9	LN	)
B6								(reset all)
RESET	ON/C	ON/C	ON/C	ON/C	ON/C	ON/C	ON/C	ON/C

Here I have added two rows and a column to reflect how the shift registers on Xanthippe are configured. When the A register puts A7 high and B6 high, for example, the pad on the reverse of the calculator is shorted, clearing all memory and putting the calculator in a fresh state. This will prove indispensable when I want to start a new session, as a reliable way to clear all memory of the previous run. There are only 7 pins on the calculator labeled B, so I have used the remaining bit there to trigger a transistor which sends an ON/C keypress.

In each byte, either none of the bits are on or one of the bits is on. None is the default state, when no button is being pushed. I never need to send an "empty press", that's just the default state in between presses. When the RESET bit is on, it doesn't really matter whether the A bits are on or off, since they can't make a full circuit without one of the B bits on as well. Therefore we can encode the keypress with just 6 bits, 3 for the A byte and 3 for the B+RESET byte. 6 bits is great, because it lets me use base 64 encoding. I like 64 bit encoding because it's standardized and human-readable.

The two numbers 0b111110 and 0b111111 have ambiguous encodings in base 64, since their original versions use the characters + and / which don't play nice in URLs. I would like to avoid them. Depending on whether I use the high bits for A or B, I could run into them or avoid them. By choosing to put B into the three high bits, I can put those in the last row of the table above. Any number of the form 0b111xxx will give a RESET, so I never need to use the two offending characters at all.

The resulting encoding is as follows.

A	B	Binary	Base64	label
0	0	000000	A	+/-
1	0	000001	B	2nd
2	0	000010	C	+
3	0	000011	D	0
4	0	000100	E	.
5	0	000101	F	SIN
6	0	000110	G	1/x
0	1	001000	I	y^x
1	1	001001	J	HYP
2	1	001010	K	-
3	1	001011	L	1
4	1	001100	M	5
5	1	001101	N	COS
6	1	001110	O	x^2
0	2	010000	Q	OFF
1	2	010001	R	pi
2	2	010010	S	X
3	2	010011	T	2
4	2	010100	U	6
5	2	010101	V	TAN
6	2	010110	W	sqrt
1	3	011001	Z	Sigma+
2	3	011010	a	/
3	3	011011	b	3
4	3	011100	c	7
5	3	011101	d	DRG
6	3	011110	e	EE
1	4	100001	h	STO
2	4	100010	i	=
3	4	100011	j	4
4	4	100100	k	8
5	4	100101	l	LOG
6	4	100110	m	(
1	5	101001	p	RCL
2	5	101010	q	ab/c
3	5	101011	r	<-
4	5	101100	s	9
5	5	101101	t	LN
6	5	101110	u	)
7	6	110111	3	(reset all)
x	7	111xxx	4,5,...	ON/C

Alas, there is no obvious rhyme or reason to how these are laid out on the calculator. Some times many buttons on the same row of the keypad will share an A pin, but this is a pattern and not a rule. I suspect it mostly has to do with whatever was convenient when the engineers at TI were laying out the traces on the keypad. I could have chosen an encoding which corresponds more to the physical layout than the electrical layout, but any such encoding would be completely ad-hoc. This encoding appeals to me because it is quite natural, and it will be easy for Xanthippe to interpret when connecting to the hardware.

The issue of how to encode the LCD still remains. There are four batches of 28 bits to store, coming from the four backplanes. For now it makes sense to defer this task, since I currently don't know what cells the majority of the bits correspond to. If, for example, they line up neatly with the 7-segment portion then it would make sense to take advantage of this. Regardless, we will certainly be able to fit the result into 14 bytes somehow, possibly padding it out to 15 bytes to make a 20-character base64 string.

How to store the tree?

We need a way for Xanthippe to keep its records, so that it knows what it has done and other software can read it. I have two bad ideas and a good idea.

First, a bad idea: I could define my own binary file format. This would let me load it fast from memory, and store it efficiently. It would also be a lot of work, and it would make it hard for other people to understand the code. If something breaks, I would not have an easy way to recover.

A less bad, but still not good, idea is to use JSON. This has the advantage of being easy for humans to read, and easy to pass between Python and Javascript. It is also a natural way to express a tree structure. There are some major disadvantages, though. I want to have Xanthippe running constantly, so it will pile up lots of data. A JSON object really would rather stay in memory while it is being manipulated, and only be written to a string when manipulations are done. If I do it this way, Xanthippe will eventually run out of memory, which will be hard to fix. JSON is also not an economical way to store binary data, in terms of disk space.

Instead I will use an actual database. This is a bit tricky since most databases are built for tables not for trees, but others have solved this problem before me. For now this will take the form of an SQLite database, since that will be the easiest to work with in Python. For the Javascript side of things, I will either figure out how to read the SQLite file directly (likely with sql.js) or have Python export it to a file for Javascript consumption. It does feel a bit silly to use SQLite to represent a tree, because to do so I must represent my data as a table which SQLite will internally represent as a B-Tree. There may be a way to give SQLite some hints as to the data structure to regain some performance, but this may also just be the price we pay for compatibility.

Next steps

Once the circuit board for Xanthippe arrives it will be time to test it out, make sure I can do the reads and writes I have designed. Exploration will probably happen with a microcontroller, but for the final result I'll probably use an old Raspberry Pi I have lying around, since I need the networking. Once I am sending keypresses and receiving raw LCD segments I will need to figure out exactly which LCD segment is controlled by which bit of the signal. After that I can get to writing the code which will run Xanthippe forever.

A 3D-printed Planimeter For Use In Classrooms

2022-07-24T00:00:00-04:00

Over the past week I have been developing a design for a 3D printed planimeter. The idea was to make something so cheap and simple that a whole class of students could each have their own, either individually in groups. I also wanted the parameters of the planimeter (the lengths of the arms) to be configurable by the students, so they are adjustable with thumb screws.

Usually, the most intricate part of a planimeter is the system of gears which allows you to count the rotations of the wheel. Here, we side-step that issue by using a 10-turn potentiometer. I intend to have students read the values using a microcontroller, and write a program to compute the area. You could also power it from a battery and use a digital volt meter. For students who are interested in electronics, it could be a nice exercise to design a circuit which runs off a 9 volt battery and displays the swept-out area in appropriate units on a cheap panel mount volt meter.

If you don't want to include electronics at all, the design could be modified to turn the wheel on a bearing instead of on a potentiometer, and markings could be added to the wheel to count rotations by eye.

I feel this is a good example of how 3D printing can change the way we teach. It would not be feasible to manufacture this type of thing for a reasonable cost using traditional methods, just because the setup time would be so great and the demand so small. 3D printing allows us to incorporate more physical activities in the classroom without breaking the bank.

Reading a Multiplexed LCD Signal

2022-07-21T00:00:00-04:00

I want to read the signal going to the display of a TI-30Xa calculator. The display has 112 segments, multiplexed in a 4x28 configuration. How can we recover the displayed values from just those 32 pins?

backplanes

First, we have to identify the signals going to the backplanes. Those don't change no matter what is displayed, always giving the same repeating signal. Using the pin assignments I chose previously, those are pins 1-4. Here is what the voltage at each of them is throughout one 24 millisecond cycle. To keep things tidy, the header row gives the time at the start of the period. The following table is in units of 1.5 volts, so that everything ends up an integer.

pin	0ms	3ms	6ms	9ms	12ms	15ms	18ms	21ms
3	0	2	2	2	3	1	1	1
4	2	0	2	2	1	3	1	1
2	2	2	0	2	1	1	3	1
1	2	2	2	0	1	1	1	3

We can see that in the second half of the cycle the same pattern of voltages is repeated. Treating each voltage as a function of time V(t), the signal obeys the rule V(t) = 3-V(t-12). In fact, every pin going to the display obeys this rule. This is done so that every LCD segment is guaranteed to see a balanced load. This leads to our first helpful observation for reading the signal.

We only need to measure the pins four times per cycle, during the first 12 milliseconds.

data

That's the four backplanes identified, what about the data pins? To give an example, let's look at pin 32. Its signal changes depending on whether the "g" in the "de/g/rad" display is on. We can test this easily, because the display will cycle between saying "deg", "rad", and "grad". By looking during the transition between "rad" and "grad", we can be sure the "g" is the only change.

pin	0ms	3ms	6ms	9ms	12ms	15ms	18ms	21ms
32(no g)	1	1	1	1	2	2	2	2
32(g)	1	1	3	1	2	2	0	2

We can see it obeys the same symmetry relation. The only difference between the two signals is in the 6 millisecond position, where it goes to 3 units when the "g" is showing. In other cases, it stays at 1 unit.

This makes sense. When a segment is meant to be off, this scheme keeps its voltage always within 1.5 volts of the four backplanes. When it is meant to be on, it goes all the way up to 4.5 volts making for a 1.5 volt difference with three of the backplanes and a 4.5 volt difference with the backplane it targets.

Assuming the others segments are driven in the same way, this tells us how to tell which are activated. For each pin, its corresponding cells will be active when it reaches 4.5 volts during each of the four measurement windows.

There are a few downsides to this scheme which we can certainly see in the final product. For one thing, every cell always has at least 1.5 volts across it, so it is very slightly on. If you hold the display at an angle, you can faintly see all the supposedly-turned-off cells. This effect goes away when the calculator is turned off for real, so it is clearly due to the multiplexing scheme.

Another downside is that cells are only activated for 1/4 the time. Presumably we could achieve deeper tone depth in the turned-on cells if they were driven the whole time.

Both of those pale in comparison to the big advantage of a multiplexed display: we got 112 segments with only 32 pins from the microcontroller, four of which are always giving the same signal.

from measurement, to circuit

To begin, let's take all 32 pins and put them into comparators. The comparators I have prefer to work near their lower voltage end, so let's use the 0 value during the second half of the cycle to read our data pins. We can get the start of our read by looking at groundplane 1, for example. This way, all our comparators can share a reference value of 0.75 volts. This gives us a clean signal we can feed into any microcontroller, with the output voltage determined by the comparator chips.

After that, we just need a microcontroller to act as a timed shift register. 29 pins (28 for data and one for the timing pulse) is too many for any of the ones I have on hand -- the Arduino Nano has 22 and the Raspberry Pi Pico has 25. I am inclined to set two Arduino Nanos on this task, each reading 14 pins, and have them communicate their combined signal to a separate microcontroller which will handle the keypad. This way I can be sure that the timing of reading the display will be handled correctly. The Arduinos can take 5 volts on their data line, so I can give the comparators extra breathing room with a 5 volt input. This is perhaps a bit wasteful, leaving 7 pins on each Arduino untouched, though of course a couple of those will be needed to communicate. The benefits are significant however: it's a modular approach which uses parts I have on hand.

luxuries

Since the comparators come in chips of four, we have enough to read every backplane for no additional cost. The Arduinos also have plenty of room to pick up the additional pins, they can certainly take in 18 pins. We could use this to shift in our data in an interrupt, without having to mess with timers. I hope this will make it more resilient against timing bugs, and make it easier to write code which handles communication since I won't need to handle reading data in the main loop.

Reverse-Engineering a Matrix Keypad

2022-07-21T00:00:00-04:00

In order to improve my calculator emulator, I am reverse-engineering a TI-30Xa. I want to be able to send key presses electrically from a microcontroller. This requires knowing the layout of the keypad matrix, i.e. what wires connect to what buttons. Unfortunately, the circuit board is riveted down with plastic. I don't have direct access to the far side of the circuit board because I want to keep the calculator in a working state.

There are a couple ways I could still get access to the other side of the circuit board.

I could get the thing x-rayed. That would be expensive. It would be way more cost-effective to just buy another calculator to disassemble.
I could drill out the rivets and replace them with appropriate screws. I'm not sure if the right screws would be a common size, so this might also get expensive. Besides, I would rather not have to take the thing apart again.

Instead, I used an indirect method. Since I have electrical access to all the test points, I can just connect an ohmmeter between an A wire and a B wire, then look for a button press which changes the measured resistance. In theory there should be one button for every pair of wires in the matrix.

Here is the result, after measuring every pair.

	A0	A1	A2	A3	A4	A5	A6
B0	+/-	2nd	+	0	.	SIN	1/x
B1	y^x	HYP	-	1	5	COS	x^2
B2	OFF	pi	X	2	6	TAN	sqrt
B3		Sigma+	/	3	7	DRG	EE
B4		STO	=	4	8	LOG	(
B5		RCL	ab/c	<-	9	LN	)

There are a few things about this layout that surprised me.

There are only 39 of the 40 keys represented here, even though there are three unused connections in the A0 spot. Further probing shows that the ON key pulls the RESET pin to ground, which we can see from the visible traces has an external pullup to B+. It makes sense in retrospect that ON would have its own pin, since they would want to activate it from an interrupt, not with the active polling that a matrix keypad requires.
B6 and A7 don't seem to be connected to the rest of the matrix. We can see on the circuit board that they are connected to either side of the RESET pad, which (if we believe what's written on the board) should put the calculator in a stable state after power loss. It's strange that this would use two pins, when the same effect could be done with a pullup and a ground. Perhaps this has something to do with wanting the RESET pad to work even if the calculator is in an off state, so that whoever is changing the battery does not need to turn the board over while it is disassembled. I don't have an explanation, it is still a mystery to me.

Since each key has two coordinates which range from 0 to 7, it seems natural to represent each key with a single byte. Three bits for A, three bits for B. That leaves two bits left over, which could be used to signal the special values ON and RESET, though of course we could also use them for something else, since we have so many of the 64 places in the table unoccupied. I am getting ahead of myself here.

Now that I know a bit more about what the wires on this calculator do, it is interesting to compare a previous revision which I have also photographed but have not probed.

A few differences are obvious -- it runs at 3 volts instead of 1.5, all the soldering was done by hand, there are six screws instead of four. If you look at the display from the front you can see it has all the same segments, though they are a bit smaller and slightly different in shape. It also has 32 wires going to the LCD, so I imagine it is driving them in the same 28x4 manner. Some of the LCD wires are also going elsewhere using vias, for example you can see S2 in the lower left. What's it doing there? Are some of the LCD wires doubling as keypad timing signals? There are only seven traces leading to the microcontroller which don't also touch the LCD, so I suppose it must be using those 15 LCD wires with vias to poll buttons some of the time.

We have the familiar A1 through A6 and B1 though B6, though no A0 or B0 so I expect they are counting from 1 in this model. There is a big A7 printed in the middle, but it doesn't seem to be associated with any one trace or pad. Most puzzling of all are the pads labeled K1 through K4. What could they be doing? Maybe in this version only 36 of the buttons are in a matrix, and the other four use pads K1 through K4.

Those questions will have to wait for another day. For now it is enough to see that in the modern revision we now have a correspondence between traces and buttons, without having to disassemble it any further.

Reflections on wiring a calculator

2022-07-19T00:00:00-04:00

This past weekend I sat down to solder some connectors onto a TI-30Xa calculator, which will be used in an upcoming project to validate the emulator I have written. This stirred up some thoughts which might be helpful to anyone who is beginning in electronics, as I once was. In no particular order, I will share those thoughts here.

Why use connectors?

The most direct way to get electrical access to a circuit is with probes -- the pointy things which come with most multimeters or oscilloscopes. In fact, that's what I used at first, to begin understanding the circuit I am dealing with. Looking at the circuit board before modification, we can see some handy labeled test points. Those are the black circles without holes in them.

You can also see the same black material up at the top, where the ribbon for the LCD is glued on. This material is electrically conductive, so we can just push a probe into it to find the signal we wish to measure.

That's all well and good for measuring one or two pins at a time. It is not so good for measuring several at once, and it is not good for making a permanent connection. Instead, we should solder onto the circuit to make the connection permanent. The most obvious way to do this would be to split apart one (or multiple) ribbon cables and leave them running out of the calculator, ready to wire onto a circuit board at the far end. I considered this. I decided against it for a few reasons, and it turned out to be a good decision.

Separation of concerns

A ribbon cable would require making every connection right on the first try. If I can use a separate wire for each connection then I have the freedom to throw it out if I make a mistake, make each connection the perfect length, and rework after the fact if I decide to change just one part. All of that would be near impossible if I were using one big ribbon cable, since all the wires used in soldering would be fused together. Also, I don't even want to think about the nightmare of keeping a bunch of loose wires in order running out of the calculator directly. The connector allows me to separate my concerns, letting me separately use the best wires for inside the calculator and for outside the calculator, without having to compromise.

Modularity

This project is an infant. I don't know what kind of circuit will be at the other end of the wires just yet -- which ones should go where? By using a connector I can easily build a simple test setup now, and replace the whole thing later once I know the permanent solution.

Reuse

In the future, I may want to repurpose this part for something else -- maybe a version of the calculator which connects to a display for projection, for example. Also, there is no reason why I should not allow it to still function as a pocket calculator. Those would be much harder to do in the future if I have a bulky bundle of wires hanging out of it. By using connectors I free myself up to do different things in the future without having to modify the calculator even further.

Choice of connector

The calculator has 32 pins going to the display, 15 for the keypad, one labeled "reset", and two battery connections. That makes 50 connections in all which I want to be able to access from the outside. What connector could be appropriate?

I have grown to like IDC connectors from prototyping, since they have the 0.1 inch pin spacing that most prototyping boards share and they are keyed preventing reverse insertion. The obvious choice for this project would be a 50 pin IDC cable, but I discarded this option for two reasons:

While the cables are readily available since they are used for 8-bit SCSI drives, the headers are not so easy to come by.
The calculator is just a bit narrower than the 50 pin header is long. Using this connector would threaten the structural integrity of the case.

I opted to use a 40 pin IDC cable, which fits nicely in the space where a solar panel would go in the school edition of the calculator. These headers and cables are also much cheaper. The down side is that I need to find a space for ten more pins. There is a common 10 pin IDC cable, but there is not enough room in the calculator for it. Two more rows of pins would spill over the top of the calculator. There is a 10 pin JST connector available which is keyed and has all 10 pins in a single row, but it is expensive in small quantities. That's why for these 10 additional pins I chose to just use a row of bare headers affixed to the case with hot glue. Not perfectly elegant, but compact and flexible enough for this project. Here you can see how it all fit together, inside and out.

If I had an unlimited budget, I think the best solution would be a DB50 D-sub connector. Since these put the pins in three offset rows they can be a lot more compact, and they are available in panel mount configurations so we could get a secure connection to the calculator case. They strike a good balance between being small enough to fit the space I have and large enough to still be able to solder individual wires. At $10 a connector and $30 a cable, the price is too much.

Because it would be unpleasant to have to trace out all the connections I just made by hand, I will relay them here in a table. Here is what each pin connects to, as viewed from the outside.

-	-	-	-	-	RESET	B6	B5	B4	B3	A7	A6	A5	A4	A3	-	-	-	-	-
B+	B2	B1	B0	1	3	5	7	9	11	13	15	17	19	21	23	25	27	29	31
GND	A2	A1	A0	2	4	6	8	10	12	14	16	18	20	22	24	26	28	30	32

B0 through B6 and A0 through A7 are the traces for the keypad matrix, matching the labels on the test pads. I have also copied the labels on the test pads for B+, GND, and RESET. I have chosen to number the traces going to the LCD in increasing order, starting from the trace nearest to the battery.

Notice I also removed the battery. The calculator would still work with the battery, and I could even read values from it with the battery installed. It would save me from having to make an external 1.5 volt source. I chose to remove the battery because it is a pain to open the calculator up, even more so now that there is delicate wiring throughout. If I left the battery in, one day I would have to open this up again to remove it, because dead batteries can leak. It is better to power it externally for the duration of this project. If in the future I want to use this as a normal calculator again then I can simply put the battery back in.

Soldering thoughts

I am not sure what the black conductive coating on the test points in this circuit are. In most circuit boards the test points and through holes are plated with a zinc alloy to make it easier to solder onto them. This board has no through hole components, so I am guessing they skipped the plating step altogether. I am guessing the coating they used is ideal for the membrane keypad on the other side of the circuit board.

Unfortunately for me, that black coating is not solderable. That means I have to solder onto bare copper. Here are some things I figured out along the way.

Flux is mandatory

The flux in the core of my solder was not nearly enough. I was able to get a connection one or two times, but the repeated heating and cooling from several solder attempts caused the copper to corrode making it impossible to connect in some places. I even broke one of the traces at one point from scraping away the corrosion too many times, which I then had to repair. These problems went away when I started using some cheap paste solder. I was able to get a good connection on the first try most of the time using flux.

Match the size of the wire to the trace

It became much easier to solder onto the traces when i started using magnet wire instead of the random scraps of wire I had laying around. It is slightly thinner than the traces I was soldering onto. This made the whole space less crowded which made it easier to make a connection without damaging a previous connection. The magnet wire was also better matched to the thermal mass of the trace, so they heated at a similar rate which made the soldering go quicker.

Mechanical contact precedes thermal contact

The soldering iron has to get the soldering surfaces hot, and it does that by touching them. If there is not much pressure between the iron and the soldering surface, heat will flow slowly. This is a particular challenge for the magnet wire, as it does not resist bending at all. In order to tin the wire, I got a scrap of wood and pressed the wire down onto it using the soldering iron. This probably also helped in scraping the insulation from the end of the wire. Doing it this way I was able to tin the end of the magnet wire quickly and reliably.

My test setup

On a project with so many parts I am bound to get confused at some point, and things are bound to not work on the first try. This means it is extra important that I always know what parts are working and what parts are not. I don't want to be debugging this circuit a month down the line to find that my problems are from a bad solder joint that went undetected. That why before and after every solder connection I tested the circuit to make sure the signal from each trace made it to its designated pin. This would get tedious if I had to put in and remove the battery every time -- I could even have damaged the battery connector doing that. Instead, I got out an LM317 voltage regulator and powered the calculator from a bench power supply. By wiring a switch in line, I could easily engage or disengage power as needed without putting wear on the calculator itself.

Before making each solder connection I probed the trace to see what signal was there. These are low frequency signals, changing on the order of 100 Hz, so it was not essential to have the oscilloscope probe grounded directly to the board -- grounding to the power supply was perfectly adequate. Once I knew the shape of signal, I could turn off the calculator with the switch, solder the wire to the connector, turn it back on, and look for the signal on the output pin. This caught faulty connections several times, which saved me the effort of going back to previous work after having already moved on.

I could have done this a more basic way, just setting my multimeter to continuity mode and probing a couple points each time, maybe checking the signals at the end using the battery. That would have been quicker to set up since all it would take would be removing the battery. The method I chose was slightly faster to use, since I only needed one hand for the oscilloscope probe. I also got a more direct confirmation that the entire path from the LCD driver to the output pin was intact. By investing a bit of time in the setup, I was able to save a lot of time during the tedious portion of the operation. This is a general principle: it's better to take the time to find a good way to do a repeated task, rather than diving in to the method with the fastest setup time.

Conclusion

Part of the joy of this hobby is finding small ways to optimize, finding a cheap solution which is still reliable and doesn't need too much labor. We got to experience some of that in picking out the connectors and wires, and ensuring reliability by testing at every stage. Another source of joy is in taking a complicated system and exploring it until you know all there is to know about it. We had to do some of that exploring here to make sure we are extracting the right test points, but mostly the wiring done here will enable us to explore the rest more easily in the future. This is a slow hobby, where we are constantly laying the groundwork for what is to come. If we already understood the circuit and knew how we would interface with it, we could jump straight to the end and print a PCB that handles most of this for us. That would also remove all of the fun, at least from my point of view.

Review: How to Do Nothing by Jenny Odell

2022-07-17T00:00:00-04:00

I know I'm late to the boat on this one. This book came out in 2019. It was one of Barack Obama's favorite books that year. I only just got around to finishing it. I don't think Jenny Odell will mind that I took this long. She seems to be okay with things that go slow.

She wisely opens the book with an old Daoist story about a useless tree. Its wood is so knotted, split, and crooked that it could not possibly be used to build anything. By being useless, it resists getting chopped down, becoming the oldest and strongest tree around.

That was the most memorable part of the book, and it plays well with the other anecdotes spread throughout. Odell resists simple instructions and admonitions by grounding each point in concrete stories, and complicating her conclusions wherever she can. Nevertheless, she has some clear and valuable messages to share.

One of those messages is that it's valuable to look backward as well as forward. Novelty is overrated. I don't hear this enough, living as I do in academia. In the academic world it goes unsaid that to be publishable (i.e. worthy of the time of an academic) an idea has to be new. This shows up in two old math cliches.

After finally completing a problem which took months or years to solve, the mathematician is distraught when they receive feedback from reviewer number 1: this problem was solved by Euler in 1775.
The student asks "why do we use this notation?", "why is this ambiguous case defined in this manner?". The teacher replies, "for historical reasons".

I invite you to imagine, if you will, an academic in any other discipline responding in this way. "Why do we call it Germany while the people there call it Deutschland?" Oh, for historical reasons.

This obsession with novelty is of course a false and dangerous one, since we are all indebted to the work and ideas of those who came before us. Without revisiting, renewing, and reinterpreting old ideas we risk losing them. There is value in learning old ways of thinking and rediscovering old techniques. When we are constantly told the opposite, it is good to hear this reaffirmed.

I won't try to summarize the book here. Instead, I will just recommend you read it yourself. It changed the way I think about some things, and made me feel a bit better about some of my weird, useless hobbies and interests.

A Two Bit Analog-Digital Converter

2022-07-12T00:00:00-04:00

For a project I am working on I need to read the signal driving a multiplexed segment LCD. The signal switches between four voltage levels (0, 1.5, 3, and 4.5), across 32 different pins. Here I will describe a few ways to recover that signal onto a microcontroller.

An off-the-shelf ADC chip

We only need two bits of information to distinguish between the four voltage levels. Even the cheapest ADCs give a whole eight bits -- the cheapest ADC on Digikey right now gives you eight bits and communicates over SPI, and would cost just under a dollar a piece. More realistically, there are eight-input ADCs which cost more like $4 each in small quantities, which would be a better deal over all.

Advantages

It's dead simple to implement, fairly easy to understand.

Disadvantages

It's power-hungry, both from the power rails and from the the data signals. An LCD driver usually has to put out basically zero current, and a low-end ADC might consume a noticeable amount, possibly more than the LCD driver is comfortable supplying.
It's noisy, since it puts a time-varying load on the signal wires.
It's expensive!

A handfull of microcontrollers

Here is a cheaper solution, which would also need way fewer parts. I have a bunch of Arduino Nano microcontrollers around, and each one has eight ADC inputs. We can set four of them to sample the circuit.

Advantages

Very few additional components, since it has most of the circuitry we need included.
Cheap: I already have them so it's basically free, but even if you didn't have them on hand the off-brand ones cost about $3 each.

Disadvantages

Still noisy and power-hungry
We have to write code for the microcontrollers

A resistance ladder (flash) ADC

A better solution is to wire up our own 2-bit ADC. A traditional way to do this would be to use three comparators and a resistance ladder. Something like this.

Advantages

Low power, low noise. If we use a good mosfet comparator this can consume basically no power except when the input value changes. The resistance ladder sets thresholds at 1.25, 2.5, and 3.75 which nicely divides the voltage levels we are comparing.
Independent of component values. We can use any resistors we like, and any comparator chip. This makes it potentially very cheap.
Solid-state. The outputs are simple digital high and low values, so we can hook them up to a shift register, or even use them for interrupts on our microcontroller. This also makes it very easy to debug, since all the logic is visible.

Disadvantages

Uses an odd number of components. Comparators are usually available in packages of two or four, and this uses three.
The output requires processing. We could take a digital output straight from the comparators, but then we would be using three wires to send two bits. We need those some additional logic chips to bring it down to two, which adds to the complexity. A repeatable unit of these on a board would necessarily process multiple signals and include several ICs so as to make use of every available gate.

A creative solution

Here is the design I have settled on.

This manages to get our output using just two comparators. The two resistors take the average from the high-bit and the 2.5 volt rail, and use that as the threshold for the other comparator.

Advantages

This has all the benefits from the flash ADC, plus it only takes 2 resistors and half of a 4-comparator IC. This makes it easier to assemble, and way cheaper -- less than 22 cents per input, in small quantities.

Disadvantages

Requires a low-impedance 2.5 volt rail. This is not a problem for me, since I have a handful of 2.5 volt regulators on hand. Of course, all the comparators for the whole project can share the same rail, so this doesn't add much to our part count. If you only had a couple of these to do, here is an alternative arrangement you could use which only needs the power rail, and a few more resistors.

This also reduces the noise on the 2.5 volt reference line, which could reduce the chance of jittering on the output. In the previous version, if signal A changes its low bit while B is changing its high bit, the small leakage from the feedback circuit of B could prevent a clean transition on A. This circuit solves that.

Generalizing

I think this is a neat topology! If you are familiar with R-2R ladders, it is probably clear to you how we could generalize this circuit to make an ADC of arbitrary precision, at least on paper. Bit n would be generated like this.

Essentially, we use an R-2R ladder as a DAC, giving the best approximation to the signal if bit n were high. We compare that to the actual signal to see if bit n should be high. Each bit only uses inputs from the higher-order bits, so I don't expect there is any danger of oscillation.

Conclusion

This is actually a special case of a really common design called a "subranging" flash. Usually designers will use more bits in a stage before going to an ADC, which gets them decreased latency and better monotonicity. Since these are usually all integrated onto a single chip they can make the priority encoder cheaply on the chip without any messy routing.

In my design it makes sense to incorporate feedback after just one bit. I get to use an off-the-shelf part (the comparator) for a very specialized purpose, all with the addition of just two resistors. It's good to keep an open mind, try out several designs, even for an undemanding task like this. Doing it the traditional way with a full 8-bit ADC on each line, or even using standard 2-bit ADC design, would lead to a needlessly expensive and complicated circuit. This custom design will do more with less.

Measures of Bimodality

2022-07-10T00:00:00-04:00

Much of my research has dealt with the problem of deciding if a sample from a random variable indicates that the underlying distribution is bimodal. We have a general intuition, passed down from Francis Galton (I'm not sure where he got the idea), that random effects tend to produce unimodal distributions. This has since then been justified using the central limit theorem -- if you have lots of small random perturbations, the cumulative effect of them will be Gaussian, and hence unimodal. If your distribution is not unimodal, his argument goes, you have good reason to believe that your data are coming from two different sources, each of which has a unimodal distribution.

This is the basic principle at the heart of the nTARP clustering procedure. In this form of projection pursuit, we seek a distribution of points which appears bimodal. We set a threshold in between the two modes, then bin the data according to which side it falls upon. We hope that, because the observed distribution is bimodal, it must have originated from two distinct sources. That is what makes it a clustering method: it seeks to break apart a signal into distinct sources, based only on patterns in the data.

Up to now, nTARP has always used the within-group sum of squares statistic, denoted W. This is used under various names in many different contexts: it is the objective function which the k-means algorithm seeks to minimize in one dimension, and also the objective function of Otsu's method for image thresholding. Our results using this method have been mixed. One one hand, when a given sample is very plainly bimodal, the statistic indicates this reliably by assigning it a small W value. On the other hand we have two significant issues:

W is significantly smaller on distributions with heavy tails. This makes it so that some distributions which appear somewhat bimodal can have a higher W than other distributions which are clearly unimodal, but which have heavy tails.
W is not stable for small sample sizes. Because W can be computed in a way which depends continuously upon the cumulative distribution function, the Glivenko-Cantelli theorem guarantees that, as the number of samples drawn from a distribution grows, the empirical W will converge to the value of W for the underlying distribution. Unfortunately, this convergence appears to be too slow in many circumstances. For certain data sets, we find that two independent samples of hundreds of points will lead to very different estimates of the population W. Note that the meaning of "small" depends on the underlying distribution in a manner I do not yet fully understand -- for some data sets it is very stable, for others very unstable.

For this reason, we are interested in looking for other tests of bimodality. That is, given a sample of several points from a one-dimensional random variable, what techniques exist to estimate whether (or to what extent) the random variable is bimodal? Here we attempt to survey a few of the most popular techniques.

A survey of tests

Statistics based on labeled data

These are generally unsuitable for clustering, because they rely on data which has already been split into two proposed sources. Most of these assume each mode of the data is Gaussian. I list a few here (from Wikipedia) for completeness.

Ashman's D
Bimodal separation
Bimodality amplitude
Bimodal ratio
Wilcock's bimodality parameter
Wang's bimodality index
Sambrook Smith's index

Linear discriminant analysis would also fall into this category, though it is less concerned with detecting bimodality than with fitting bimodal data.

Kurtosis

There have been decades of arguments at this point over exactly what qualitative features are encoded by kurtosis. The only one which is generally uncontroversial is that distributions with high kurtosis have "heavy tails". Of course, this is in some sense kicking the can down the road, since people may mean different things by "heavy tailed". One of the more controversial perspectives is that kurtosis measures how bimodal a distribution is. This is usually justified by the observation that a Bernoulli random variable, which is in some sense the ideal bimodal distribution, minimizes the kurtosis among those distributions with a common variance. This interpretation is frowned upon by some, but is still widely used by researchers analyzing ordinal data with a bounded support, such as Likert scales. For a sophisticated discussion, see "Kurtosis Measures Bimodality?" by David Hildebrand.

Bimodality coefficient

This one is attributed to various sources, but certainly goes back at least to Karl Pearson. (skewness^2+1)/kurtosis. The rationale is the same as for kurtosis, but it always gives a number between 0 and 1. I have not found any strong theoretical justification for this statistic. One reason for its wide use is that it is available in many common statistical software packages, such as SAS. Another is its age -- it is well-established.

Sturrock's index

A Gaussian fit is performed (any model could be used in principle, but they chose Gaussian), giving a theoretical CDF. The inverse CDF is applied to the data mapping them to quantiles between 0 and 1. Sturrock's index is the spectral power of the resulting distribution due to the frequency 2. This technique is essentially equivalent to comparing the empirical CDF to the theoretical CDF on a P-P plot. Their strategy is quite ad-hoc, probably appropriate for their domain, but would not generalize to other types of data very well. In particular, it would only make sense over a certain range of separations. The strategy of comparing the empirical CDF with a theoretical CDF is very general, and could be used to quantify how well any sample matches a given theoretical model. This would more accurately be termed a test for discrepancy from a proposed theoretical CDF, rather than a true test of multimodality. It gets to be on this list because it is substantially different from any of the other tests described here.

Hartigan's dip test

This is based on comparing the empirical CDF to the nearest unimodal CDF. Hartigan and Hartigan show that the nearest unimodal CDF is always a mixture between the empirical CDF and a uniform distribution. The dip statistic can be computed efficiently, using some FORTRAN code which has been passed around since the 80s and translated into other languages. This only gives an index; to make it into a proper "test", Hargian and Hartigan suggest computing it on samples from a known distribution for comparison.

Silverman's kernel density test

Silverman takes the problem of estimating a kernel density bandwidth, and turns it on its head. Usually, to get a good kernel density estimate, you need unimodal data. By choosing the smallest bandwidth which keeps the estimate unimodal, you can resolve as much detail as possible without introducing artificial wiggles. It becomes a problem if the data are bimodal, because this approach would smear out the distribution removing all detail. Silverman takes this burden and turns it into an asset: by looking for distributions which require a large bandwidth to reach unimodality, we can pick out those which are bimodal. Silverman also gives a significance test, based on bootstrapping.

As Hartigan and Hartigan note, this statistic has the disadvantage of depending on the scale of the data. You can normalize the data of course, but care must be taken to do so fairly. This would also naturally deal poorly with heavy-tailed distributions, where there are regions which are severely undersampled. Another disadvantage is that is is slow to compute. If a Gaussian kernel is chosen then the number of modes depends monotonically on the bandwidth, which allows for a binary search, but Silverman does not propose any better technique than this.

I do wonder whether we could get somewhere with a slightly more subtle version of this test, somewhat akin to the Topologist's bar codes. Might we say the correct bandwidth is not where the data becomes unimodal, but where the modality of the data does not depend strongly on the bandwidth? That is, there should be a wide range of bandwidths over which the density estimate has the same modality. That range might tell us more than just a single number can.

information-theoretic approaches

Some people seem to be applying an information-theoretic approach as well, to see whether a two-component mixture model does a significantly better job of expressing the information in a sample. This is a purely parametric approach, in that the underlying distribution is assumed.

Conclusions

Three of the above methods see widespread use across disciplines: the bimodality coefficient, the Hartigan dip test, and Silverman's kernel density test.Many papers cite these three together, in a scattershot approach to statistical analysis. For some reason, the statistic W only sees much use in the image processing community, presumably due to the influence of Otsu's method for image segmentation, and even there is goes by another name. I have not seen much written with the goal of improving on these statistics. I think most authors find it more valuable to have statistics which are directly comparable to other researchers' numbers, rather than seeking marginal improvements to the computation methods.

Of course, if a parametric form for the data are known, far more options are available -- one could use gradient descent to estimate parameters, for example. In the case where more is known about the parametric form of the data, we would expect a custom method to work better in principle because it does not have to learn what we already know. We are looking for a truly general statistic, something which does not depend on the form of the distribution. This rules out most published approaches other than the four identified above.

Pinball Science

2022-02-22T00:00:00-05:00

the game

One of my favorite video games from childhood was Pinball Science. It seems that it was mostly sold (in the US in any case) at Scholastic book fairs, to accompany the book The Way Things Work by David Macaulay. It's hard to find much about it online. The best source I have found is this youtube video, where someone in a similar situation to me managed to get it running in a virtual machine. I have had no luck running it on a virtual machine. This is not terribly surprising, since it never ran particularly well even when it was new -- the loading times were long, and it was prone to graphical glitches and crashes. The only way I have personally gotten it working in recent years was by installing Windows 98 on a contemporaneous laptop.

installation woes

If you want to run it, you may find yourself in a pickle due to a subtle problem. Pinball Science is compatible with Windows XP, but not every version is compatible. If you go looking online, you may find ISO copies of the disk. Out of all those I have checked, none will run on XP without additional configuration. This is because Pinball Science relied on behavior which changed in Windows XP Service Pack 1. The DK website (when it was still up) claimed that they did publish a version of the disk which is compatible with XP including later service packs, but I have never found a copy of that disk.

Do not despair: they published a patch which I have used before with success. It used to be available for download from their website, but their website went offline many years ago. Archive.org does have a backup of that website including a backup of that patch file. Just in case, I have also hosted that file here. For what it's worth, here is a link to another patch from that publisher, which claims to be compatible with service pack 2 and has a different file name; however, the files appear to be identical. I have also rehosted that patch here, just in case.

multiple versions

I have found at least two versions of the installation disk, and I believe there are more. These are the two versions I have in my possession. I have posted ISO copies of these disks on my Github.

Scholastic

This seems to be the earlier one; all the files on it have a modification date of 1998 or earlier. When loaded on Windows, the name of the disk reads as DKMMTWSW.

Case:
Disk:
Front:
Back:
Inside:
Inside back:

Global Software Publishing

This one is more recent, as some of its files have a modification date of May 15 2002. Since XP Service Pack 1 would not be released until November of that year, it seems unlikely that this would have the service pack 1 patch. Notably, it appears to have dropped support for MacOS, presumably because OS X came out the previous year and would be incompatible with this game, which was written with System 7 in mind. When you load this in Windows, the name of the disk reads as Dkmmtwsw.

Case:
Disk:
Front:
Back:
Inside:

The New Way Things Work

There's not much online about Pinball Science, but there is even less about the companion disk The New Way things Work. Perhaps it would be more accurate to say Pinball Science was the companion disk. Here's how the parentage seems to go:

There is a book The Way Things Work released in 1988
There is a CD-ROM version released in 1994, which features animations and quizzes as well as text from the book. The idea seems to have been a children's digital encyclopedia, in the style of Encarta.
In 1998 an updated version of the book is released, The New Way Things Work, featuring material about digital electronics. Separately, an updated version of the CD-ROM encyclopedia is sold, in a box set together with Pinball Science.

I remember having a copy of The New Way Things Work around when I was little, but I don't remember anything about its contents. It must not have been too much fun, at least in comparison with Pinball Science. In any case, I have also preserved an ISO of this disk along with the scans below. When loaded in Windows, the name of the disk reads as DKTNWTW.

Case:
Disk:
Front:
Back:
Inside:
Inside back:

What's Inside "The REAL Cotton Candy Maker"?

2019-10-01T00:00:00-04:00

When I was a child, I once owned a toy called "The REAL Cotton Candy Maker". It made cotton candy a couple of times, in small quantities. It stopped working after a few uses, for a reason I do not recall. Perhaps I never knew.

Recently, I had the good fortune to find a used version of the same toy at a flea market for a couple dollars. I bought it, tried it out, and determined it did not work. I figured I would take it apart, and see what I could see.

Above is the circuit diagram I reconstructed. Here are a few observations:

The circuit uses a reed relay to determine whether the lid is closed and in place. This is hooked up at JE1, on pin 7 of U2.
JE2 is connected to a hall effect sensor, which detects a magnet on the machine's rotating shaft.
JE3 is just connected to a couple LEDs.
I have no idea what pin 11 of U2 is for. It seems to go out to a pad where it can be accessed. Perhaps this is used for programming the chip.

What was wrong with my particular model? I will never know, because I got bored and threw it out. My hope is that the diagram I worked out along the way will someday help someone in a similar situation to diagnose more quickly, and perhaps get an answer.

	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1
A	5DP	5D	6DP	6D	7DP	7D	8DP	8D	9DP	9D	M3	2nd	A	.	.	.
B	5C	5E	6C	6E	7C	7E	8C	8E	9C	9E	10G	HYP	.	B	.	.
C	5B	5G	6B	6G	7B	7G	8B	8G	9B	9G	M2	ENG	.	.	C	.
D	5A	5F	6A	6F	7A	7F	8A	8F	9A	9F	M1	SCI	.	.	.	D

-	-	-	-	-	RESET	B6	B5	B4	B3	A7	A6	A5	A4	A3	-	-	-	-	-
B+	B2	B1	B0	1	3	5	7	9	11	13	15	17	19	21	23	25	27	29	31
GND	A2	A1	A0	2	4	6	8	10	12	14	16	18	20	22	24	26	28	30	32

	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1
A	5DP	5D	6DP	6D	7DP	7D	8DP	8D	9DP	9D	M3	2nd	A	.	.	.
B	5C	5E	6C	6E	7C	7E	8C	8E	9C	9E	10G	HYP	.	B	.	.
C	5B	5G	6B	6G	7B	7G	8B	8G	9B	9G	M2	ENG	.	.	C	.
D	5A	5F	6A	6F	7A	7F	8A	8F	9A	9F	M1	SCI	.	.	.	D

-	-	-	-	-	RESET	B6	B5	B4	B3	A7	A6	A5	A4	A3	-	-	-	-	-
B+	B2	B1	B0	1	3	5	7	9	11	13	15	17	19	21	23	25	27	29	31
GND	A2	A1	A0	2	4	6	8	10	12	14	16	18	20	22	24	26	28	30	32

Alden Bradford

An old statistics exam

Pass the Pigs for Teaching Statistics

The problem

Enter the Pigs

Additional exploration

We should all use OpenIntro Statistics

Background

Necessary improvements

Retrospective One-Tailed Tests

T test or Z test

Technology

The TI-84

Spreadsheets

R

Using Real Data

Topic Coverage

Stem-and-leaf plots

Probability Theory

Aesthetics

Recommendation

An Even More Straightforward Proof of Descartes’s Circle Theorem

Solution to a puzzle on the incircle of a triangle

The puzzle

The solution strategy

The arithmetic

Conclusion

Orrell's Quick Wall Paper Calculator

How it works

The mystery

My proof of Descartes's theorem was just published

Another little puzzle

A simple geometry puzzle

Hints

Hint 1

Hint 2

Hint 3

Hint 4

A Cubic Spline for Animation

The setting

The clever bit

Computing it

Continuity

Smoothness

Solving for \(A\)

Applying the formula

Conclusion

A Problem in Optimal Transport

The proof

When \(x_2>y_2\)

When \(x_2<y_2\)

Conclusion

An intuitive proof of the Descartes circle theorem

Heron's formula and the Cayley-Menger determinant

The proof

The details

Return to Battleship

The tool

The good

The bad

The janky

Conclusion

Decoding a multiplexed LCD

Naming conventions

The table

The backplanes

DEGRAD

Indicators

Digits

Exponent

Conclusions

Lessons from the Xanthippe circuit board

Board size

Default behavior

Resistor arrays

TO-92 footprints

Breakouts

Disconnects

Conclusion

Revisiting Apollonian gaskets

	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1
A	5DP	5D	6DP	6D	7DP	7D	8DP	8D	9DP	9D	M3	2nd	A	.	.	.
B	5C	5E	6C	6E	7C	7E	8C	8E	9C	9E	10G	HYP	.	B	.	.
C	5B	5G	6B	6G	7B	7G	8B	8G	9B	9G	M2	ENG	.	.	C	.
D	5A	5F	6A	6F	7A	7F	8A	8F	9A	9F	M1	SCI	.	.	.	D

-	-	-	-	-	RESET	B6	B5	B4	B3	A7	A6	A5	A4	A3	-	-	-	-	-
B+	B2	B1	B0	1	3	5	7	9	11	13	15	17	19	21	23	25	27	29	31
GND	A2	A1	A0	2	4	6	8	10	12	14	16	18	20	22	24	26	28	30	32