In the prior post, we looked at a number line on a slinky, and picked an equivalence relationship simply based on which numbers are vertically aligned.  We’re going to take a closer look at slinky arithmetic,

mapping numbers onto the slinky as below – so that 5 ends up directly above 1, and 6 directly above 2, etc.:

It may be helpful to think as the “1″ position as South, the “2″ position as East, the “3″ position as North and the “4″ position as West.  As you move around the spiral, you keep coming back to South etc, but you’ll be a little higher up.

Now let’s look at arithmetic on the slinky, starting with addition.   We can take some well-known addition fact, like
5 + 10 = 15, and then note the compass positions of the numbers involved.  5 is South, 10 is East, and 15 is North.  The question I’m now curious about is: If I start with a number in the South and add a number in the East, will I always end up with a sum in the North? After all, the compass directions seem to have nothing to do with how high up we are.  On this number line, East comes after South, and North comes after East, and West comes after North, and after West comes South again.

In the diagram above, the top line shows the compass marks for the numbers from 0-18.  The diagram at the bottom left shows  a normal addition table.  In the table on the right, all the numbers from the left have been replaced by their compass markings.  As you can see, the pattern on the right is completely regular and repeats after 4 rows, after 4 columns and after 4 diagonals.

From that table on the right, we extract a four-by-four core piece, and show it below.  It is this piece that repeats over and over.  We can translate the compass marks back into numbers, as shown below on the right.  We used the numbers 0-3 as representatives of the equivalence classes – unlike the situation in the prior post, we now have at least some reason to pick this set of numbers over other numbers.

In some regards, the table on the right does look like an addition table: most of the entries match what we would expect.  It is only where we would normally expect a sum of 4 or greater that the table looks somewhat strange.  Instead of 4, we find 0; instead of 5, we find 1, and instead of 6, we find 2.  This is at least consistent with the equivalence relationship we’re looking at here: 4 is directly above 0, 5 is directly above 1, and 6 is directly above 2 in our slinky.

The style of addition in this last table has a fancy name: it is known as addition modulo 4.  The same phrase, modulo 4, is used to talk about equivalence classes for whole numbers: when any two numbers that are 4 apart are considered equivalent.  For example, people would say that 5 and 9 are equivalent modulo 4, and that 9 and 13 are equivalent modulo 4.  By extension, 5 and 13 are also equivalent modulo 4.  Some people would describe equivalence modulo 4 in terms of division: two numbers are equivalent modulo 4 if they have the same remainder after dividing by 4.  Yet another way to talk about it is in terms of multiples: two numbers are equivalent modulo 4 if they differ by a multiple of 4.  All these ways of talking about it amount to the same thing, but that may not be immediately obvious.  “Two numbers are equivalent modulo 4 if they point in the same compass direction on the slinky” also expresses the same idea.

So far, we’ve talked about modulo 4 and only looked at the operation of addition modulo 4.  We can extend in both directions: we could look at subtraction, multiplication, and division modulo 4.  We could also extend in a different way and look at equivalence modulo 5 or modulo 6 etc.  We will take this up in future posts.

In this post I want to get started on playing with what’s known as modulo arithmetic, also called modular arithmetic, from our framework of operators and equivalence classes and properties.

As a starting point, let’s take another look at the number line.  In this older post, I suggest that this one thing, the number line, takes on a different character as students progress from using it for counting to – much later – locate numbers like π and √3 on it.  When we are just counting, the fact that the numbers on the number line are carefully spaced is not critical – but what is important is that the mark for 4 comes after the mark for 3 and the mark for 5 comes after the mark for 4, etc.  The number line is usually drawn as a straight line, but this may only be critical once we start to use number lines as axes on graphs.

The measuring tapes shown above, whether in inches or centimeters, are essentially number lines also, though they aren’t necessarily straight lines.  If you measure things with them, you probably want to stretch them out to be straight – but if you want to use them for many of the functions you use a number line for, it may be quite sufficient to unroll the tape enough so you can see the numbers you care about.

You could even take a slinky and turn it into a number line.

To do so, you would have to put markings along the rim.  Though the slinky would never be suitable for measuring like a measuring tape, it might serve quite well as a number line.

A sketch of one possible such number line is shown below:

The numbers 1-7 are shown; the slinky extends in both directions, as indicated by dotted lines.  Numbers are shown evenly spaced – in this particular example, precisely 4 whole numbers are placed along each circle.  For example, by the time we get to “5″, we are exactly where “1″ was, just slightly above it.

In prior posts, we’d look at a particular operation, and then decide on equivalence classes based on equal values of that operation, this time we’ll turn things around, and decide on the equivalence classes first.   Can we do this and get away with it?  Sure, if we cast it in terms of: “with respect to what operation(s) will these equivalence classes in fact be equivalent?”

On the slinky number line just sketched, we are going to consider the equivalence classes based on vertical alignment, like this:

Another way of talking about this equivalence is that we consider equivalent all numbers that are 4 apart.  The representatives of these equivalence classes, just like in our earlier posts, are found at the end points of the blue arrows.  So 1, 2, 3 and 4 are the representatives.  There is nothing magical about this particular choice, you can make a very good case for using 0, 1, 2 and 3 as the representatives instead.  We could also have picked -2, -1, 0 and 1.  In a sense, it is too early to argue which make for the best representatives – we haven’t looked at relevant operations yet.

In the next post, we’ll apply this particular equivalence structure to the operations of addition and subtraction.

x

In this post, I’m going to develop a similar theme with multiplication and multiplication tables.  In the diagram on the left, I’ve drawn a simplified multiplication table, only going up to 5.  In the middle, I’ve repeated all that information but this time drew some contour lines connecting entries with the same value for the multiplication result (the product).  Compared to the addition case in the prior post, the contour lines are no longer straight.  Only some of the contour lines are shown, but you can get a good idea about the others, especially since 1.5, 2.5, 3.5 and 4.5 are marked also.  Finding the product associated with any point in that middle diagram is directly analogous with how you find the altitude on a topographical map such as the one shown on the right.

In such a topographical map, the contour lines represent locations of equal altitude.  You can see contour lines marked for elevations of 400 ft and 350 ft (this is  a US Geologic Survey map) with 4 contour lines separating them.  From this you can conclude that adjacent contour lines are 10 ft in latitude apart.  The altitude of any point on this map can be estimated fairly accurately by looking at contour lines below and above.

It’s the same with the product.  In the middle diagram, the contour lines are drawn 2.5 apart, from 0 to 25, though the contour line for 0 is not strictly on the diagram itself, but rather just beyond the top left corner.  You could draw contour lines 1 apart instead, and this certainly would remove the need for estimating if what is being multiplied is two whole numbers (from 1 to 5).  Of course, the need for estimating would rear its head in the same way, when you wanted to use the map for multiplying numbers that weren’t whole numbers.  And you could.  The  middle diagram is a simple (and somewhat crude) example of a class of computational devices called nomographs, of which the Wikipedia entry provides some interesting examples.  Now largely replaced by electronic devices, for centuries nomographs represented the most sophisticated computing devices available.  (A particularly versatile and useful one, for centuries,  is the slide rule.  I still have the slide rule I bought for college, in those days obligatory for math/science/engineering students.  The real geeks of the day had them hanging from their belt.)

seems seriously lacking.  The box on the right is an attempt to clean this up a bit.  Sales are not a function the price.  From a known price, the sales volume is not uniquely determined.  In the language of our operators and our state machine black boxes, we’d say that there are hidden variables or hidden state that affects the output.

The issue here, by the way, is not that the description inside of the box (“Prius”) doesn’t tell us precisely enough how to calculate the sales demand from the price as a given input.  For all we know, the Prius box contains an big look-up table with the data from some massive earlier experiment in which prices were varied.  Such a look-up table would be a fine way to build a function box.  The issue, rather, is that price clearly isn’t the only thing that determines sales volume.  Yet if we do manage to hold all the other potentially relevant variables constant – in other words, if we can really deliver on the ceteris paribus, then, yes, we’d have an example of a function.

In the previous post we also emphasized that a function doesn’t necessarily have its own matching undo.  But let’s be more precise: a function doesn’t necessarily have a matching undo function.  Computer programs often build undo-functionality by squirreling away some extra data.  For example, if you delete a word, and then “undo” that delete, the program can retrieve the word that you deleted since it didn’t really delete it, it just squirreled it away.  This copy of the deleted word is then part of the state of the machine, part of what is usually known as hidden state.  By looking closely at how a program like Microsoft Word behaves, you can make up a decent model for what is going on.  Microsoft Word operates on state, and the state is not just what is currently in the document, but also what is in its undo and redo stack.  When you start Word, or whenever you save a document, these stacks are emptied.  When you do something in Word, like typing, or deleting, or changing the font of a selection, an entry is added onto the undo stack, and each entry is specific enough so that the action can not only be undone, but also be re-done after undoing it.  When you undo something, the last entry is moved from the undo stack to the redo stack.  These stacks of undo/redo entries are fully part of the state on which Word operates.

For the mathematical notion of a function, it is essential that there be no hidden variables, that all dependencies are shown.  So when we write , we think of x as the input, y as the output, and while we may at times insist that a,b,c are not variables, we nevertheless make them explicit, and give them some kind of appropriate name (parameters, or unspecified constants) that indicate that we think of them as fixed.  In we have a different situation, where is thought of as a name for a specific number, or perhaps as a shorthand for the decimal expansion of that number.

OK – so now let’s briefly introduce properties, and then come back to those in more detail as well.  Our starting point will be a state machine, one of the type we introduced in part 6 of this series:

A state machine has one or more buttons that invoke operators; when invoked, such an operator takes the current state of the machine, operates on it, and produces a new, updated state.  Not all of the state is necessarily visible; typically, what shows on the screen is only a small portion of the machine’s state.  Even on the simplest four-function calculator, there is a number being kept in the calculator that the screen does not show.  If you enter “2+3=”, then at the moment the “3″ shows on the screen, the ’2″ is no longer showing – but we all know it is still “there” in some sense; after all, when you hit the final “=” button, the screen will show “5″, so clearly more was ‘kept around’ than just that “3″.  And yet, clearly, what is shown on the screen depends on the state of the machine.  In fact, what’s shown on the screen is an aspect of the state, a piece of the state, a component of the state.   Here, we’d say that the screen content is one of the properties of the state.

We can look at properties as special kinds of functions, ones that usually don’t have an undo function.  These functions can act on state, as in our example of the calculator screen above, or they can act on numbers, as in many of our examples of operators.  Imagine a box that determines whether the number on its input is even or odd, and puts a value on the output accordingly – this will be an example of a property operator, and one we will pursue in an upcoming post.

But before I do so, I want to ‘fess up’ to something.  It’s the kind of thing that irritates me when I see others do it.  I did something that didn’t make any particular sense in the context in which I used it – it only makes sense in a future setting, in this case a setting that is several posts away.  We do this in math class all the time: we put the motivation into the future “some day this will all make sense.  You need this because of the 9th grade test, or because of graduate school.”  Instead, I think it is really important that the math makes sense now, always now, not in the future.
Truth is that my displaying the vector inner product using one horizontal vector and one vertical vector was not something that was particularly appropriate in the problem setting that I used.  It may have gotten in the way somewhat.  So let me correct that here and use a representation that is appropriate to the situation at hand.

Instead of this representation:

it would be more natural to use a representation like this (which more closely matches many order forms you may see):

This representation matches more clearly how most of us would think about an order being priced. The two starting vectors(the order vector and the price vector) can be seen in this arrangement, though they are a bit indistinct.  If you’d feel better if the blank entries are replaced by zeros, you are welcome to do it that way:

OK – now on to other examples of inner products.

Weighted Average – One that most teachers are familiar with is that of computing an average score based on a series of tests, each with its own weight.  So let’s say there was a test in September, and one in October, and one in November, and a final in December.  Let’s say the scores on each are in the range from 0 to 100, and that the final is supposed to count twice as heavily as the other tests.

The weights vector would be:

The weight vector is the same for all students, and is independent of the scores.

A particular student would have a set of scores.  Let’s assume Jesse’s scores are like this:

The final score for Jesse would be the inner product of his score vector and the weights vector:
60 × .20 + 70 × .20 + 50 × .20 + 100 × .40 = 12 + 14 + 10 + 40 = 76.

(This matches the result you’d get if you took the average of 60, 70, 50, 100, 100 where you’d repeat the December score twice.  That’s another way to give the December score double the weight of the others.  60 + 70 + 50 + 100 + 100 = 380, and if you divide that by 5 – which is the number of scores added together – you get the same 76.)

Total Calories – Just like we can price an order by computing the inner product of the order vector with a price vector, we can get the total calories of an order by computing the inner product of the order vector with a calorie vector.

Number of Cups – We can keep track of inventory through inner products, too.  A store will typically want to replace the inventory that’s been sold, and for that it wants to keep track of the total amount sold.  This is probably most useful  when done for a particular period, like a day.  To keep the example simple, let’s assume we’re keeping track for each single order (and then add these up for all orders in a day).  The store would want to keep track of the number of hamburger patties used up, the number of slices of pickle used, etc.  In this example, we’ll keep track of the number of cups used for a particular order.  Again, this can be done by taking the inner product of the order vector with the following vector:

which we might name the “cup vector”.  You can verify for yourself that the inner product of our example order

with the cup vector would yield 3 cups.  For (3×1 cup) + (1×0 cups) + (5×0 cups) + (2×0 cups) = 3 cups.

We’ll see more examples of inner products later, including geometric examples.  I think we’ve got enough here to gives us a natural introduction to a new topic in the next post: we are going to introduce matrices.

In  this post, I will combine vectors with look-up tables and thus introduce an operation usually called inner product.  For this, we will take as our starting point the drive-up window order from a previous post:

The box above represents the order, and we have been assuming that this order is specific enough that the fast food folks can get you what you want.  Specifically, that there is an understanding of what an order of “coke” is as compared to, say, “coke, small”, or “diet coke, large”.

Yet serving up your order is not the only concern of the fast food place.  They need to get paid.  They charge you for the items ordered, based on a price list.  (And then, in the USA and some other countries, they compute taxes on top of the total; in yet other countries, the taxes would already be included in the prices shown on the price list.  In this post, I’ll ignore taxes altogether.)

The price list can also be shown as a vector.  It might look like this:

The price list will typically contain many items that weren’t ordered.   Typically, there is an entry in the price list for any item ordered.

To find the total amount (ignoring taxes), it is pretty clear what needs to be done: for each item ordered, you multiply the amount ordered by the price found from the price list vector, and then you add it all up.

The $15.10 comes from coke (3 times $1.20) plus cheeseburger (1 times $1.50) plus hamburger (5 times $1.40) plus fries (2 times 1.50).

The operation on the order vector and the price list vector that gives us the final price (ignoring taxes) is called inner product.  I don’t want to go into the significance or the origin of the name (though you would correctly guess that there is also something called an outer product.)  Inner product is also often called the dot product.

You may have noticed that the situation shown is not symmetric with respect to the two vectors.  Yet there are ways to make the similarity between the two vectors more pronounced.  One way to do that is to ignore the parts of the price list that aren’t being called upon.  We can also reorder the entries to match those of the order.  Doing so might give us something like this:

Alternatively, we could expand the order to match the price list, by explicitly  marking zeros for those items on the menu that aren’t ordered.  This is something we may show later.

For now, I will note that textbooks sometimes show this inner product as follows:

where the information that gives us the meaning of the 15.10 is left out, but at least the distinction between the two operands of the operation is maintained.  But since the process of multiplying and adding is itself commutative, there are many textbooks that dispense with the different treatment of the two operands altogether and write the thing as (3,1,5,2) • (1.20,1.50,1.40,1.50) = 15.10 and treat it as a completely symmetric operation: (1.20,1.50,1.40,1.50) • (3,1,5,2) = 15.10.  I will come back to these more subtle points in a later post.  What I hope I have achieved in this post is that you see how the scenario of an order – written as a vector – combined with a price list – also written as a vector – naturally leads to a process that gives us a single number, and that this process matches what textbooks call inner product.

Each counting number n past 1 is assigned a successor number, as follows:

The number “1″ is considered home, and when you’re home, you stop.  If you start at a given number away from home, and cycle through its successors, you may end up home.  Is there any starting number from which you will not eventually reach home?

When playing with a starting value of 6, we found that the travel path took us to 3, to 10, to 5, to 16, to 8, to 4, to 2, and finally to 1.  We observed that in finalizing this path from 6 to 1, we have also solved the path from 3 to 1, and the path from 10 to 1 and so on.  The sieve we introduce in this post will take full advantage of this observation.  Unlike the sieve in the prior post, this sieve will work essentially forward.

First, we decide how big the sieve is going to be.  For our examle, we will make the sieve size 16.  Each cell in the sieve will have two numbers and a marker.  The marker can have the following values “not visited”, which we will represent by a blank; “tentative”, represented by a “-”; “succeed”, represented by a “+”, and “fail”, represented by a “≠”.  A typical transition will be from blank to tentative to succeed (“-” to “+”); sometimes it will be from tentative to fail (“-” to “≠”).  Below are a series of snapshots:

The first snapshot is how we start out: all cells are marked “unvisited” (blank) except for the first cell, which is completed as “succeed”.  In each step, we look for an unvisited cell and then do a sweep.  The second snapshot shows what happens when we visit cell 2.    When we visit cell 2 we mark it as “tentative”, and then do a sweep by marking its successors, in turn, as tentative as well.  As we do this, we keep a running count of how many cells we mark tentative this way.  The “tentative” sweep ends in one of two ways.  One, we encounter a cell already marked “succeed”.  If so, we do a final sweep, starting at the same cell (here marked in red).  In the final succeed sweep, we mark all the cells “succeed” and fill in the time slot.  We have the information we need for filling in the time slot: we add our count of tentative markings to  the time value we found in the “succeed” cell we ran into.  For each successor cell we decrease the time value, till we bump into the cell already marked as succeed.  The third snapshot shows the result of the final succeed sweep for 2.

We now visit the first unvisited cell, which is cell 3, and mark it “tentative”.  Similarly, we mark its successors as tentative, marking 10, 5, 16, 8 and 4 this way.  Our running count indicates we have marked 6 cells as tentative.  The next successor cell, 2, is already marked “succeed”.  So we can now do a final succeed sweep, starting at 3.  The time slot for 3 will be filled in as 8, the sum of our running count of 6 and the value we found in the “succeed” cell of 2.

The fourth snapshot shows the result of the final succeed sweep for 3.  This sweep visits the same values, and in the same order, as the tentative sweep, always going from a value to its successor.  We can stop this sweep when it arrives at a cell already marked as “succeed”.

After visiting 6, both the tentative sweep and the final sweep, the result looks like the first snapshot above.  Something new happens when we visit 7, mark it tentative, and mark its successors.  Here, we encounter the case where the successor does not lie inside of the sieve that we constructed.  The successor of 7, 22, is outside the sieve’s range of 1 through 16.  In this case, we do a final “fail” sweep, starting at 7.  A “fail” sweep works just like a “succeed” sweep, except we mark the cell as “fail” and don’t bother with the time slot.  The last snapshot above shows the result of this.

The snapshot below shows the result of continuing this process till all cells in the sieve have been visited and swept:

Note, first of all, that marking a cell as “fail” doesn’t mean we’ve found a counter example to the Collatz question.  Instead, it merely indicates our sieve wasn’t big enough to settle the issue.  Note, second, that we paid for the relative straightforwardness of this sieve’s forward actions by needing to do a final sweep to ratify and record the result of the tentative sweep.  This is true both in case the tentative sweep succeeds and when it fails.  Note, third, that compared to the predecessor sieve we showed in the earlier post, this sieve is easier to extend.  If after completing the size 16 sieve I decide I want to complete a size 1000 sieve, I could start with the completed size 16 sieve and simple erase all the fail markers: all the succeed markers can be left in place.

Isn’t it interesting that two such very different sieve processes both serve to construct travel paths home for a range of starting points?  In the process, they have revealed a number of key characteristics of sieve processes.

Let’s suppose I have a folder of test sheets from a standardized test.  Each piece of paper in the folder is from a particular student, and is marked with a score from 0-20.  On a long table, I make room for 21 stacks of test sheets, side by side, by putting down yellow stickies each marked with one of the possible scores from low to high.  I then take the test sheets, one by one, and place them in the stack corresponding with the score on the sheet.  If Jesse’s sheet is marked with score 15, that sheet will go on the stack labeled 15 on the yellow sticky.  When I’m done placing all the test sheets, I end up with a number of stacks of varying heights – and some stacks may be empty.  Below is a representation for what I ended up with:

The usual name for this representation is histogram.  My highest stack had eight test sheets in it, for score 15.  Score 10′s stack was empty.  Jesse’s sheet is somewhere in the 15 stack, but my representation doesn’t show where in the stack it is.  Each box in my representation could have been marked with the student’s name, but I didn’t do that.  As with any representation, this representation highlights certain information and leaves out other information altogether.  One thing left out is the name of the student, another thing is any information on the order in which the sheets were in the original folder.  If I had shuffled the sheets in the folder, the representation as shown would have been identical.

What information can we extract from these representations?  Quite a bit, actually.  Some are simple and some are useful.  A simple thing we can see from the representation is that nobody had a score of 10, nor a score of 11.  Of course, neither the histogram representation, nor the stacks of sheets with the yellow sticky was critical to finding this out.  I could have answered the question “how many students have a score of 10?” by flipping through the entire stack of sheets and counting the ones that have a score of 10.  If that was the sole thing I cared about, it might even have been a bit faster and simpler doing it that way.  Yet, after I answered the question “how many 10′s?” I would have had to do the same amount of work all over again if there was a follow-up question; “how many students have a score of 20?”

One side effect of putting the test sheets in stacks based on their score is that we have now effectively sorted them by score.  If we were to put them all back in a single stack again, by collecting the individual stacks in score-order, the resulting stack is sorted by score.  If I divide the sorted stack in half, I’ve located the middle value (called median – though median is a technical term, and I have left out the precise rules for what to do when the number of sheets in the stack is even, and what to do if it’s odd.)  If I divide the sorted stack in five equal parts, I get the quintiles, if I divide the sorted stack in four equal parts, I get the quartiles.

The histogram also allows me to answer questions like “what percentage of students scored 16 or above?”  All of those questions could have been answered from the original pile of test sheets, but the histogram makes it more straightforward.

The process of getting the histogram has clear parallels with the various sieves I’ve shown in earlier posts.  Enough so, that my claim that sieves and look-up tables don’t have much support in the K-12 curriculum was too hasty.

If you look today for the kind of look-up tables that in the past were a mainstay of K-12 math textbooks: reference tables in the back of the book, you will see very little.  In high school textbooks, you might still find small tables for sin, cosine and tangent, perhaps for logarithms.  In earlier grades, you might find a list of prefixes for the metric system, like milli- and Mega- and nano-, with explanations how big or how little each is.  You are unlikely to find, at any grade level, a simple multiplication table shown for reference purposes.  Instead, the multiplication table is assumed to be committed to memory.

In contrast, textbooks half a century ago would pay great attention to look-up tables.  Even if an extensive logarithm table wasn’t part of the reference section of the textbook, it would be published separately and used by students.  Yet the textbook would have a section on how to use such tables.  Look-up tables weren’t considered a crutch – they were considered the real thing.  There would likely also have been tables for square roots, cube roots, reciprocals, and lots of other stuff.

It’s fairly easy to justify why all that stuff is gone or de-emphasized, and that is the availability of calculators and computers that can quickly do the calculations that once were the domain of those look-up tables.  Why sift through pages of tables to find the cosine of 79 degrees if you can find out with a few keystrokes on your scientific calculator or spreadsheet?  Those vestigial log and trig tables that I did see in the high school textbook appendices seem disconnected from anything students or teachers do.

Other look-up tables, not math related, are also their way out.  Every year several phone books, white pages and yellow pages, are dumped on our doorstep and we turn right around and put them in the recycling bin.  It’s been over a decade since I’ve looked up a number in a paper phone book.  And when is the last time that you looked up a word in a paper dictionary or a paper encyclopedia?  Or a quote in a book of quotes?

And yet it is clear that the issue is paper, not look-up.  What is Google other than superbly organized look-up?  Google Maps, Google Earth, Google News, iTunes music downloads: all look-up.  The face of look-up has changed.  Instead of a person flipping pages, look-up now happens behind the screen.  Who knows or cares what’s happening behind that screen, it is somehow doing the look-up, not you.

For many centuries, there has been a trade-off in mathematics and engineering between calculation and look-up.  More look-up meant you needed to do less calculation, and less look-up meant more calculation.  The trade-off shifted back and forth dependent on the cost of producing tables, and the cost of computation.  Publishing tables only took off when paper became relatively inexpensive.  Napier, around 1614, published extensive logarithm tables, which took years of hard work to complete.  Such tables saved generations of engineers time and errors in doing calculations.  The earliest computing machinery, mechanical and later electronic, was very expensive and included almost no storage capacity whatever – just enough for the two numbers to be added and their sum.  When addressable storage became feasible – still extremely expensive – we saw the rise of stored-program digital computers and the use of look-up tables became possible again, but now under the covers of the machine.  With a modern calculator such as a TI-84, you’d have a hard time finding out to what extent the calculator is relying on table look-up internally for it to calculate any of its functions.  Same with computers – not too many years ago, a three-dimensional role playing game might pre-compute the look of your avatar at a number of different angles, e.g. in 15 degree intervals, and only ever show your character at those angles.  Trade-offs between the cost and speed of computing versus the cost and capacity of the various hierarchies of storage continue to shift back and forth with interesting consequences: the iPod only became feasible after massive storage capacity became small, cheap, fast, and yet would keep its content even with power turned off.

There is rich and interesting mathematics involved both in creating look-up tables, and in using them.  This mathematics highlights the computational structure of numbers and operations.  Much of it can be introduced in grade-appropriate forms throughout K-12.  I intend to share my thinking about this in future posts.

There are many kinds of sieves, and we’ll see one later in this post.  The essential characteristic of a sieve, from where I look, is that it reverses direction.  Instead of doing a tricky determination for a single number, like finding out if a number is prime, we do a larger number of easy, systematic, steps, and collect the results in a look-up table.  The results we get not only tell us if the specific number we cared about is prime, but also gives us all the smaller primes.  If we want multiple primes, this look-up approach is quite efficient.  Look-up tables have many uses beyond sieves, but in this post we’ll stick to sieves.

Let’s introduce a new term, “final odd”, and give it a particular meaning.  We’ll say that the “final odd” of 20 is 5.  How you get the final odd is to cut the number in half repeatedly, until you get to an odd number.  If the number is odd to start with, you don’t need to do anything.   Sounds simple enough, right?  If we start with 48, you would proceed to cut it in half repeatedly, getting 24, 12, 6 and finally 3.  If this thing we’ve called “final odd” is something you needed a lot, it might make sense to make a look-up table. Let’s assume we’ve been working on this look-up table, and have gotten this far:

and we now need to fill in the entry for 8 and onward. We know how to calculate the final odd for 8: the sequence we calculate is 8, 4, 2, and 1. But everything after the first step of calculating 4 is a repetition of what we already did to find the final odd of 4, and the result of all that work is already in the table.  As you can see, this will apply generally: with the look-up table, you never need to do more than one step of cutting the number in half.

But we can improve on this even more, and make it into a real sieve. For this, we determine upfront the size of the table we are going to fill in.   We’re only showing a table with 8 entries, but you can easily extend this to be longer.

We find the first unmarked entry, and then do a sweep based on that. Here, the first unmarked entry is 1, and we can fill in its entry. We can now repeatedly double the number, and give it the same entry. This gives

We repeat this process for what’s now the first unmarked entry, the third entry.

The last two sweeps are easy, and complete the table:

Note that we ended up with the same lookup table as before, but without having to do any divison.  We didn’t even have to do multiplication, just doubling, which we could do by adding a number to itself.  Also note that in this case, we didn’t particularly make use of the values in the table while building the table.  The only use we had for the values when we were building the table is to find the first entry in the table that hadn’t been filled in yet.  Some sieves depend both on the values previously stored in the table and on finding unmarked entries.  We’ll see an example of that in a post soon.