I am embarrassed that after writing 72,650 words about MLX 2.0 for last week, I left something out. Specifically, I didn’t include code for your own simulation of the checksum routine on a more modern platform. Here’s a function that carries out the calculations of the Commodore 64/128 or Apple II versions of MLX 2.0. It’s written in Octave, the open-source Matlab-like numerical computation routine. If you can read this, though, you can translate it to whatever language you find convenient.
function [retval] = mlxII (oneline)
z2 = 2;
z4 = 254;
z5 = 255;
z6 = 256;
z7 = 127;
address = oneline(1);
entries = oneline(2:9);
checksum = oneline(10);
ck = 0;
ck = floor(address/z6);
ck = address-z4*ck + z5*(ck>z7)*(-1);
ck = ck + z5*(ck>z5)*(-1);
# This looks like but is not the sum mod 255.
# The 8-bit computers did not have a mod function and
# used this subtraction instead.
ck = ck*z2 + z5*(ck>z7)*(-1) + entries(i);
ck = ck + z5*(ck>z5)*(-1);
# The checksum *can* be 255 (0xFF), but not 0 (0x00)!
# Using the mod function could make zeroes appear
# where 255's should.
retval = (ck == checksum);
This reproduces the code as it was actually coded. Here’s a version that relies on Octave or Matlab’s ability to use modulo operations:
function [retval] = mlxIIslick (oneline)
factors = 2.^(7:-1:0);
address = oneline(1);
entries = oneline(2:9);
checksum = oneline(10);
ck = 0;
ck = mod(address - 254*floor(address/256), 255);
ck = ck + sum(entries.*factors);
ck = mod(ck, 255);
ck = ck + 255*(ck == 0);
retval = (ck == checksum);
Enjoy! Please don’t ask when I’ll have the Automatic Proofreader solved.
So my question from last Thursday nagged at my mind. And I learned that Octave (a Matlab clone that’s rather cheaper) has a function that calculates the day of the week for any given day. And I spent longer than I would have expected fiddling with the formatting to get what I wanted to know.
It turns out there are some days in November more likely to be the fourth Thursday than others are. (This is the current standard for Thanksgiving Day in the United States.) And as I’d suspected without being able to prove, this doesn’t quite match the breakdown of which months are more likely to have Friday the 13ths. That is, it’s more likely that an arbitrarily selected month will start on Sunday than any other day of the week. It’s least likely that an arbitrarily selected month will start on a Saturday or Monday. The difference is extremely tiny; there are only four more Sunday-starting months than there are Monday-starting months over the course of 400 years.
But an arbitrary month is different from an arbitrary November. It turns out Novembers are most likely to start on a Sunday, Tuesday, or Thursday. And that makes the 26th, 24th, and 22nd the most likely days to be Thanksgiving. The 23rd and 25th are the least likely days to be Thanksgiving. Here’s the full roster, if I haven’t made any serious mistakes with it:
||Will Be Thanksgiving
||times in 400 years
I don’t pretend there’s any significance to this. But it is another of those interesting quirks of probability. What you would say the probability is of a month starting on the 1st — equivalently, of having a Friday the 13th, or a Fourth Thursday of the Month that’s the 26th — depends on how much you know about the month. If you know only that it’s a month on the Gregorian calendar it’s one thing (specifically, it’s 688/4800, or about 0.14333). If you know only that it’s a November than it’s another (58/400, or 0.145). If you know only that it’s a month in 2016 then it’s another yet (1/12, or about 0.08333). If you know that it’s November 2016 then the probability is 0. Information does strange things to probability questions.
I realize that I’m probably about eight years behind the curve on this one, but I only just learned that the National Center for Education Statistics has this cute little create-a-graph application (Flash required), good for whipping up several of the name-brand graphs out there.
The pie chart is particularly nice since I’ve never figured out how to make pie charts in Octave (it’s probably some tricky command like ‘pieplot’), and they have a neat historical resonance because they were turned from one of the many obscure tools of the then-obscure field of statistics into the first rank of mathematical tools by Florence Nightingale. She used them as a way to communicate, efficiently, what the causes of death in the Crimean War were.
This gives me use a fine narrative hook in class: I can ask them if they know who first made pie charts famous, and then insist they do indeed, they just never had any idea about it.
I have a couple of other thoughts about these piecewise constant functions which I’ve been using to make interpolations. The basic idea is simple enough; we pretend the population of Charlotte was a constant number, the 840,347 it happened to be on the 1970 Census Day, and then leapt upwards at some point to the 971,391 it would have on the 1980 Census Day. Maybe it leapt up immediately after the 1970 Census; maybe immediately before the 1980; maybe at the exact middle moment between the two; maybe some other day. Are those all the options we have?
Continue reading “The Jagged Kind Of Flat”
Putting together links to all my essays about trapezoid areas made me realize I also had a string of articles examining that problem of The Price Is Right, with Drew Carey’s claim that only once in the show’s history had all six contestants winning the Item Up For Bids come from the same seat in Contestants’ Row. As with the trapezoid pieces they form a more or less coherent whole, so, let me make it easy for people searching the web for the likelihood of clean sweeps or of perfect games on The Price Is Right to find my thoughts.
Continue reading “About Chances of Winning on The Price Is Right”
One week, it seems, isn’t enough to tell the difference conclusively between the first bidder on Contestants Row having a 25 percent chance of winning — winning one out of four times — or a 17 percent chance of winning — winning one out of six times. But we’re not limited to watching just the one week of The Price Is Right, at least in principle. Some more episodes might help us, and we can test how many episodes are needed to be confident that we can tell the difference. I won’t be clever about this. I have a tool — Octave — which makes it very easy to figure out whether it’s plausible for something which happens 1/4 of the time to turn up only 1/6 of the time in a set number of attempts, and I’ll just keep trying larger numbers of attempts until I’m satisfied. Sometimes the easiest way to solve a problem is to keep trying numbers until something works.
In two weeks (or any ten episodes, really, as talked about above), with 60 items up for bids, a 25 percent chance of winning suggests the first bidder should win 15 times. A 17 percent chance of winning would be a touch over 10 wins. The chance of 10 or fewer successes out of 60 attempts, with a 25 percent chance of success each time, is about 8.6 percent, still none too compelling.
Here we might turn to despair: 6,000 episodes — about 35 years of production — weren’t enough to give perfectly unambiguous answers about whether there were fewer clean sweeps than we expected. There were too few at the 5 percent significance level, but not too few at the 1 percent significance level. Do we really expect to do better with only 60 shows?
Continue reading “Proving Something With One Month’s Counting”
We have some reason to think the chance of winning an Item Up For Bids, if you’re the first one of the four to place bids — let’s call this the first bidder or first seat so there’s a name for it — is lower than the 25 percent which we’d expect if every contestant in The Price Is Right‘s Contestants Row had an equal shot at it. Based on the assertion that only one time in about six thousand episodes had all six winning bids in one episode come from the same seat, we reasoned that the chance for the first bidder — the same seat as won the previous bid — could be around 17 percent. My next question is how we could test this? The chance for the first bidder to win might be higher than 17 percent — around 1/6, which is near enough and easier to work with — or lower than 25 percent — exactly 1/4 — or conceivably even be outside that range.
The obvious thing to do is test: watch a couple episodes, and see whether it’s nearer to 1/6 or to 1/4 of the winning bids come from the first seat. It’s easy to tally the number of items up for bid and how often the first bidder wins. However, there are only six items up for bid each episode, and there are five episodes per week, for 30 trials in all. I talk about a week’s worth of episodes because it’s a convenient unit, easy to record on the Tivo or an equivalent device, easy to watch at The Price Is Right‘s online site, but it doesn’t have to be a single week. It could be any five episodes. But I’ll say a week just because it’s convenient to do so.
If the first seat has a chance of 25 percent of winning, we expect 30 times 1/4, or seven or eight, first-seat wins per week. If the first seat has a 17 percent chance of winning, we expect 30 times 1/6, or 5, first-seat wins per week. That’s not much difference. What’s the chance we see 5 first-seat wins if the first seat has a 25 percent chance of winning?
Continue reading “What Can One Week Prove?”
When last we talked about the “clean sweep” of winning contestants coming from the same of four seats in Contestants Row for all six Items Up For Bid on The Price Is Right, we had got established the pieces needed if we suppose this to be a binomial distribution problem. That is, we suppose that any given episode has a probability, p, of successfully having all six contestants from the same seat, and a probability 1 – p of failing to have all six contestants from the same seat. There are N episodes, and we are interested in the chance of x of them being clean sweeps. From the production schedule we know the number of episodes N is about 6,000. We supposed the probability of a clean sweep to be about p = 1/1000, on the assumption that the chance of winning isn’t any better or worse for any contestant. The probability of there not being a clean sweep is then 1 – p = 999/1000. And we expected x = 6 clean sweeps, while Drew Carey claimed there had been only 1.
The chance of finding x successes out of N attempts, according to the binomial distribution, is the probability of any combination of x successes and N – x successes — which is equal to (p)(x) * (1 – p)(N – x) — times the number of ways there are to select x items out of N candidates. Either of those is easy enough to calculate, up to the point where we try calculating it. Let’s start out by supposing x to be the expected 6, and later we’ll look at it being 1 or other numbers.
Continue reading “A Simple Demonstration Which Does Not Clarify”
It seems to me that I need to factor numbers more often than most people do. I can’t even attribute this to my being a mathematician, since I don’t think along the lines of anything like mathematical work; I just find that I need to know, say, that 272,250 is what you get by multiplying 2 and 3 to the second power and 5 to the third power and 11 to the second power. And I reliably go to places I know will do calculations quickly, like the desktop Calculator application or what you get from typing mathematical expressions into Google, and find that since the last time I looked they still haven’t added a factorization tool. I have tools I can use, particularly Matlab or its open-source work-just-enough-alike-to-make-swapping-code-difficult replica Octave, which takes a long time to start up for one lousy number.
So I got to thinking: I’ve wanted to learn a bit about writing apps, and surely, writing a factorization app is both easy and quick and would prove I could write something. The routine is easy, too: take a number (272,250) as input; then divide by two as many times as you can (just one, giving 136,125), then divide by three as many times as you can (twice, giving 15,125), then by five as many times as you can (three times, reaching 121), then by seven (you can’t), then eleven (twice, reaching 1), until you’ve run the whole number down. You just need to divide repeatedly by the prime numbers, starting at two, and going up only to the square root of whatever your input number is.
Without bothering to program, then, I thought about how I could make this a more efficient routine. Figuring out more efficient ways to code is good practice, because if you think long enough about how to code efficiently, you can feel satisfied that you would have written a very good program and never bother to actually do it, which would only spoil the beauty of the code anyway. Here’s where the possible inefficiency sets in: how do you know what all the prime numbers up to the square root of whatever you’re interested in is?
Continue reading “How I Make Myself Look Foolish”