2013

An item in the Sydney Morning Herald's Column 8 mentioned the following interesting mathematical tidbit - 2013 is the start of a uncommon triplet of years which are all the products of three distinct primes - 2013 = 3 x 11 x 61,  2014 = 2 x 19 x 53, and 2015 = 5 x 13 x 31.

When did this last happen? In 1885 (5 x 13 x 29),  1886 (2 x 23 x 41), 1887 (3 x 17 x 37), and before that, only in the years 1309 (7 x 11 x 17), 1310 (2 x 5 x 131), 1311 (3 x 19 x 23). It won't happen again until 2665 (5 x 13 x 41), 2666 (2 x 31 x 43), 2667 (3 x 7 x 127).

After that, the next such triplets are 3729-3731 and 5133-5135, but then it happens 5 times in the 7th millenium (6061-6063, 6213-6215, 6477-6479, 6853-6855 and 6985-6987).

So if you want to stimulate a discussion about factors and/or prime numbers, 2013 is a great year.

When True Was True When It Should Have Been False

(or Why The Devil Is In The Details)

Another 'whoops' moment in class today - another little lesson learned by the teacher: always read the documentation carefully.

In this case, my students had been given the problem of how to 'clean up' a list in Python so that it contained only integers or floats – any strings, tuples, booleans, etc. would need to be removed.

A simple enough task - simply loop over the list and check the type of each item. But here's where the documentation (or more precisely, a cursory read of it) lead us astray.

The Python docs say this about the inbuilt type() function:

type(object)

Return the type of an object. The return value is a type object. The isinstance() built-in function is recommended for testing the type of an object.

So we should use isinstance()? Okay, let's look at that then:

isinstance(object, classinfo)

Return true if the object argument is an instance of the classinfo argument, or of a (direct or indirect) subclass thereof.

So, we can do something like isinstance(i, (int, float)) to check the if the type of i is an integer or float.

And all seemed well right up to the point when this list:

[3, 4.5, "word", True, (3, 5)]

should have been reduced to:

[3, 4.5]

but instead became:

[3, 4.5, True]

Wha...? How did that boolean slip through?

Back to the documentation:

isinstance(object, classinfo)

Return true if the object argument is an instance of the classinfo argument, or of a (direct or indirect) subclass thereof. 

When we look at the documentation on numeric data types, we find this:

There are four distinct numeric types: plain integers, long integers, floating point numbers, and complex numbers. In addition, Booleans are a subtype of plain integers.

So this:

isinstance(True, int)

returns True rather than False.

I can see some good reasons why booleans have been defined as a subtype of integers (and it's not only Python where this is the case), but it caught us offguard all the same.

So the point of today's lesson - read the documentation carefully, make sure you get your head around the finer details. Not the point I had planned to make, but maybe a better lesson as a result.

You learn something new every day

Today I attempted to correct a problem in a FileMaker database - and screwed it up badly. (Thank goodness for back-ups.)

The problem concerned some data that had not transferred properly during a change-over between two systems - some dates in the old system had appeared in the new as plain integers instead of dates.

A quick experiment showed me that the GetAsDate() function in FileMaker Pro would convert the number to the correct date - simple. So I duly went ahead and made the change to the data in-place. I know better than to do this, of course, but I was in a hurry and didn't want to take the time to export out the data, convert it and import it back in. So you can imagine my expression when those numbers turned not into the dates I was expecting, but instead into question marks, Filemaker's way of indicating that the data was now invalid.

Grabbed a back-up and retrieved the numbers, but what went wrong?

Doing what I should have done first time, and examining matters more thoroughly, I discovered something that I would not have expected. My initial experiment involved taking a number from a number field and converting it using GetAsDate(). But in the actual database, I was taking numbers from a date field and trying to convert them using GetAsDate(), and this doesn't work. It seems that retrieving a number (invalid data) from a date field does not return the number, and GetAsDate() consequently fails.

It became more interesting when I tried (on a separate file derived from the back-up) to use GetAsNumber() on those numbers in the date field - they all came back as 0. Okay, that doesn't work.

So, one more try - what does GetAsText() return? Aha! I get the number - as a text string. But now I have my answer - GetAsDate(GetAsNumber(GetAsText(theDate))). Problem solved.


You learn something new every day. And sometimes you get to learn an old lesson all over again.

A Pythagorean Curiosity

Today a colleague asked me to construct a nice question around Pythagoras' Theorem.

Toying with various ideas, I came up with the following figure:

Now it's easy enough to replace a, b, d and e with values, scrub c and one of the right angle symbols and then ask the students to show that the triangle must be right angled. But of course I wanted a nice set of integers for this question, so I wrote a little Python program to generate integer solutions to the set of equations:

Here's the first 30 solutions (given in the form {a, b, c, d, e}):

{9,12,15,20,25}, {16,12,20,15,25}, {18,24,30,40,50}, {25,60,65,156,169}, {27,36,45,60,75}, {32,24,40,30,50}, {36,48,60,80,100}, {45,60,75,100,125}, {48,36,60,45,75}, {49,168,175,600,625}, {50,120,130,312,338}, {54,72,90,120,150}, {63,84,105,140,175}, {64,48,80,60,100}, {64,120,136,255,289}, {72,96,120,160,200}, {75,180,195,468,507}, {80,60,100,75,125}, {81,108,135,180,225}, {90,120,150,200,250}, {96,72,120,90,150}, {99,132,165,220,275}, {100,240,260,624,676}, {108,144,180,240,300}, {112,84,140,105,175}, {117,156,195,260,325}, {125,300,325,780,845}, {126,168,210,280,350}, {128,96,160,120,200}, {128,240,272,510,578}

What stood out was that in most of these, e was a multiple of 5. When I isolated the instances where e was not a multiple of 5, I found that either a or b was!

My first version of my Python program only examined values of a and b up to 1000, so of course I ramped it up a little - to values up to 1000000 for both a and b.

And it still appears to be true. In every solution my program has generated, either e is a multiple of 5 or a or b is.

Looker closer at Pythagorean triplets in general, it is known that at least one number in a Pythagorean triplet has to be a multiple of 5. So if a and b are not multiples of 5, c must be. But if c is a multiple of 5, the Pythagorean triplet of {c, d, e} does not require that e also be a multiple of 5, and yet that appears to be the case for the figure at the top if it is to have integer sides where a and b are not multiples of 5.

Now if I could prove that this it always the case!

Update: when I showed this to another colleague, she pointed out the obvious fact that I had overlooked, namely that the two triangles in the diagram are similar.

Now the matter becomes simple.

Suppose that a is a multiple of 5. Given that the triangles are in the ratio a:c and a and c are the corresponding sides of the two triangles, we find that

and for e to be an integer would mean that c² must be divisible by a and therefore divisible by 5, and therefore c must be. So both a and c will be multiples of 5. Now it's easy to show that if two of the numbers in a Pythagorean triplet are multiples of 5, the third must be a multiple of 5 as well, so we conclude that if a is a multiple of 5, so are b and c.

What if a is not a multiple of 5? As at least one number in a Pythagorean triplet must be a multiple of 5, if a is not, then either b or c is.

If b is the multiple of 5, c will not be. As stated before, the triangles are in the ratio a:c, so we find

and therefore d is also a multiple of 5. As c is not, we conclude that e is also not a multiple of 5.

The third possibility is that c is the multiple of 5. Again, noting that

but this time, where a and b are not divisible by 5, we conclude that e must be a multiple of 5 as well, and thus d must be as well.

So we find that the possibilities are as follows:

• if a is a multiple of 5, b and c are multiples of 5 as well (and d and e may be as well)
• if a is not a multiple of 5 but b is, then d is as well but c and e are not
• if a and b are not multiples of 5, c must be, and d and e will be as well

Now I can sleep!

A Little Geogebra

I am getting to really like Geogebra. I've had my Year 8 class working on it to explore the properties of quadrilaterals, and my wunderkind Mitchell is now exploring circle geometry with it.

This week I was introducing Yr 8 to linear functions. The textbook does the usual dull thing of showing a table of values like this:

x	1	2	3	4	5
y	1	3	5	7	9

and asking the students to determine the 'rule' that connects x and y.

But I have a laptop and a projector on the ceiling, so let's make it more interesting. Fire up Geogebra, and drop some points onto the cartesian plane like so:

Now I can ask the students some questions: Are these points on a straight line? Does the fact that they are on a straight line mean that there is some connection between the x-coordinate and the y-coordinate for each point? (To which I got the reply, "There must be, or you wouldn't have asked." I didn't mind that, it was the next statement that threw me - "No, Mr D often asks weird questions"!)

Having decided that there may be a connection, the students put there heads together and came up with an answer, which then gave me the opportunity to ask how we would write that as a mathematical statement. Having decided on 'y = 2x -1', Geogebra then allowed to neatly type exactly that into the input field at the bottom of the window - the line appeared on screen passing through all the points, and the students were quite pleased with themselves.

A few more examples done the same way and the students had clearly grasped the concepts I wanted to get across. One boy asked a nice question about expressing one of our 'rules' differently (x in terms of y) which led to some useful discussion.

What I found most pleasing about this was the ease with which I was able to do what I needed. Simply being able to type in the equation as I would write it on the board made the connection all the more obvious to the students. I could have done the same thing with Geometer's SketchPad (and I still like GSP for certain things), but Geogebra seems easier and more intuitive for a lot of this type of work.

Geogebra - my students are going to be seeing a lot more of it.

Spam Leaking In

Lately, this blog has been targeted by spammers. To be precise, Chinese speaking spammers with Google/Blogger accounts. It appears that somewhere in China (or Singapore?), individuals are creating Google/Blogger accounts for the express purpose of being able to put spam into comments on blogs like mine that require users to have such an account in order to comment.

I know this is not Google/Blogger's fault. But it would be nice to have an option to not just reject a comment, but also flag the commenter as a suspicious account for Blogger to investigate. Maybe one day.

In the meanwhile, to my spamming 'friends', I say: STFUAPO!

Addendum: in light of the fact that spam comments have continued, and I'm tired of seeing them appear in my inbox for moderation, I've limited comments to blog members (i.e. me.) Anyone wanting to comment for now will need to email me instead.

Game: Set and Match

I love Python. Have I mentioned that before?

I learned programming first as a student teaching myself BASIC on an Apple ][. When I got to Uni, I was initiated into the ways of FORTRAN and Pascal. I got to grips with C, and later as a teacher, I became familiar with Javascript and PHP. I've even spent some time tackling Java and C++.

But is wasn't until I started seriously looking at Python as a replacement for Pascal in my teaching programs that I started to appreciate the differences between various languages and how this affects the way I program.

And I find programming in Python to be a real joy. I find it flexible and easy to read, but replete with functionality. As a language to teach to students, it fills my requirements beautifully.

I'm sure that others will prefer different languages (and I have spent a little time on Ruby, and I can see its appeal), and for various reasons. I'm well aware that performance-wise, there are many languages that execute faster than Python. I came across an example of this only the other day. Andrew Choi is a computer scientist, who is also a jazz enthusiast, like me. He's written programs to generate jazz accompaniment in MIDI. One program was originally written in Python, but then Andrew rewrote his program in OCaml and achieved a massive increase in performance.

So would I consider switching to OCaml? Have you looked at OCaml?? OCaml is what you get when you let a programming language be designed by a committee.¹ I'll stick to Python.

An example of what I find so nice about Python: I posed a problem to my students the other day about looping over a list and clearing out duplicate elements so that only a single instance of any particular element remained. The students came up with a couple of ways of doing this, but their approaches, as you might expect, involved looping over the lists. But Python (typically) provides more than one way to tackle this problem.

Consider a list with duplicate elements:

>>> L = [1, 2, 3, 2, 3, 2, 2, 3, 1, 5]

Python lets you remove the dupes from this list using a single line of code:

>>> L = list(set(L))

That's it! Don't believe me? Try it for yourself.

I hadn't really looked at Python's set type before, I think mainly because the resources I've relied on to learn about (and teach) Python have made little mention of it, which is a bit odd, given how useful set operations are. (Though that may be the mathematician/database developer sides of me coming out.)

Need to match up the common elements in two lists (call them A and B)? The answer is as simple as this:

>>> common = list(set(A) & set(B))

How simple is that!

Did I mention that I love Python?

---

1. With apologies to Mark Twain.

User Interfaces and MathML

An article on linguistic user interfaces caught my attention the other day. I like Jono DiCarlo's theory about what makes for a good user interface: easy to learn; efficient; expressive.

It struck me later that DiCarlo's theory helps to explain what I see as the main difficulty in working with MathML. If you are someone who wants to construct equations in MathML to display on your website, in all likelihood you have been using some tool, probably a WYSIWYG one with a drag-and-drop or palette-based interface, to construct the equations which then generates the MathML for you. You then need to transplant this into your website.

So what's wrong with this? While these tools and their interfaces meet the criteria of easy to learn (usually) and expressive (usually), they are definitely not efficient. GUI-based interfaces are easy to learn and use, but they are also comparatively slow next to keyboard-based input methods. And having to move the generated MathML to your webpage is another bottleneck.

But thankfully there appears to be some light on the horizon. Peter Jipsen of Chapman University has created a javascript script (called ASCIIMathML) that converts structured text to presentation MathML. So you can type `x=(-b +- sqrt(b^2-4ac))/(2a)` into your webpage and what appears is the quadratic formula. If the ASCIIMathML script is missing, the expression is still reasonably comprehensible. Compare that to the following MathML for the same formula:

<math xmlns="http://www.w3.org/1998/Math/MathML">
 <mi>x</mi>
 <mo>=</mo>
 <mfrac>
   <mrow>
     <mo>−</mo>
     <mi>b</mi>
     <mo>±</mo>
     <msqrt>
       <msup>
         <mi>b</mi>
         <mn>2</mn>
       </msup>
       <mo>−</mo>
       <mn>4</mn>
       <mi>ac</mi>
     </msqrt>
   </mrow>
   <mrow>
     <mn>2</mn>
     <mi>a</mi>
   </mrow>
 </mfrac>
</math>

ASCIIMathML in my opinion represents a huge step forward. It begins to address the efficiency problem by allowing the user to enter equations without needing another tool, or having to open up and click on palettes, or having to copy the MathML from one place to another.

I've added ASCIIMathML to my school's Moodle server - my students can now enter equations simply by typing. They can mouse over equations that I've placed in pages on Moodle and copy the ASCIIMath expression and then change it as they need to. And all this without sacrificing ease of learning or expressiveness. The basic syntax is very easy to learn, but extends in a logical manner to cover even extremely complicated expressions.

Now all that's needed is for the makers of all browsers to include support for MathML, including the requisite fonts, by default.

The Pluses Problem

On his blog, Rational Mathematics Education, Michael Goldenberg mentions this problem by way of one Maria Miller (her blog here.)

How many addition signs should be put between digits of the number 987654321 and where should we put them to get a total of 99?

Michael finished his blog entry with "It would also be great if anyone has other extension ideas for this ... The one I'd suggest right away is: What happens if we change 99 to other values?"

This got me thinking along a slightly different line - what other totals have multiple solutions and could I write a program to find them?

It turns out that there are 209 possible totals (including 987654321), of which 31 can be formed in more than one way. Four totals (153, 171, 180, 189) can be formed in four different ways, seven totals can be formed in three different ways, and the rest in two different ways.

The program to find this is conceptually quite simple... if you can get your head around recursion.

The logic: for a given number, take the first n digits (where n is progressively a number from 1 to the total number of digits), convert to a single value, then with the remainder, do the same thing again.

Programming this in Python ended up being simple, but not before I went down a few blind alleys:

def Chunkit(x,p=[]):
for i in range(len(x)):
   p.append(int(x[:i+1]))
   if i == len(x)-1:
       print p, sum(p)
       print
   else:
       Chunkit(x[i+1:])
   p.pop()
return p

num = raw_input("Enter a number: ")
Chunkit(str(num))

The sticking point was line 9:

p.pop()

At first, it's not obvious why this is necessary, but if you leave it out (as I initially did), you soon see the consequences.

With the program written and working correctly (with a few additions to produce the list of totals and how often they occur), exploring the original problem led to the results given above. It also allowed me to examine different number sequences, such as 123456789, which can be made to total 99 three different ways rather than two. (And totals of 153 and 162 can be made five different ways.) Or 123454321, which can be made to total 97 in eight different ways.

Of course, having posted here what I think is a fairly neat solution (only 13 lines of code), no doubt some script-kiddy will pop up with a four line solution in Ruby or OCaml or whatever is the trendy language this week. But at least I now have another interesting problem to discuss with my students.

A lattice for multiplication

When I was in Year 5, our teacher showed us an interesting way of multiplying. The image at left shows the lattice or gelosi method for mutipying 35 x 76. You put the numbers to multiply along the top and the right sides, with sufficient rows and columns for each digit. Each box is divided diagonally. You multiply (in any order) and the result goes in the appropriate box, with the tens above the diagonal and the units below. Once all the multiplications are done, you add along the diagonals (the red arrows in my pic), starting from the bottom right corner, working to the left and carrying where necessary.

As a method for long multiplication, it works very nicely, and is probably a little simpler to learn than the more usual columnar approach. It is certainly worth showing to students - some will no doubt prefer the standard columnar approach, but others will like the lattice (at least until they get calculators).

But the other day I found another use for the lattice. I was introducing a Year 10 class to multiplying polynomials. I used a lattice (minus the drawn diagonals) as shown at left. We collected the like terms (which conveniently lie diagonally). My students found this approach very accessible. While I did not suggest it on the day, an obvious way to speed up this approach is to omit the variables and work with only the coefficients.

Then I happened to look at a blog I've been occasionally reading, and the lattice was mentioned there as well. But in this case, it was about someone arguing against using the lattice method in the classroom. Say what? Sadly, it is true - there are those who would have teachers confine themselves to teaching only one way (in this case, the standard columnar approach), and who disparage any other approach and denigrate anyone who would teach any other approach.

I can't even begin to fathom the mental bankruptcy necessary to say to someone else "there is only one way that students should do it". For me, part of the beauty of Mathematics is that there is always more than one way. Some ways will be faster or more elegant. Some ways will be slow wandering paths, but you may learn other things along the way.

The person who insists that students do things only one way is no educator.

Magic squares? Mind-reading? High school maths, and nothing more.

I've come across an interesting site (which was advertised on another site I found through StumbleUpon), featuring a supposedly mind-reading magic square.

This site gets the user to choose a two digit number at random, and then subtract from this number the values of its digits, e.g. if you chose 87, you would then subtract 8 and 7 from 87 to get 72. You then look at a grid showing numbers and symbols, and find the symbol corresponding to your result.

The site tells you it will guess your symbol correctly three times, then if you pay $2 via PayPal, you can get five more guesses and a presentation about the "Secret to Life". And you can pay $20 to have the secret of the magic square explained to you.

Of course, there is no magic, and no mind-reading, and a bit of elementary maths can quickly reveal what's going on. This is actually a good exercise for both Mathematics and Computer Studies classes - construct a spreadsheet or computer program that shows all the numbers from 10 to 99 and the result after subtracting the number's digits from itself. Once you've done that, the trick is obvious.

What about the "Secret to Life"? I didn't pay to find out, but I suspect it might be that a fool and his money are soon parted.

Get me the poll position, stat!

The stirring stuff for the media this weekend, especially the News Ltd. outlets, was the Galaxy poll that shows the Government slipping behind again. The key points for the talking heads and their opinion-column analogues in the papers were the poll results showing most Australians were skeptical of the Government's motives for the current intervention in the NT, and the fact that voters were largely unconcerned about the influence of the Unions on the ALP.

The media love to make a big deal of polls. This would appear to be consistent with Ehrlich’s Law: “People pay way too much attention to things that are easily quantified.” But does this poll really tell us much?

For one thing, the sample was only 1000 people out of the 10 million in this country who can vote. I have some doubts about how much we can assume from so small a sample (~0.01%). (I'd love to see the pollsters publish the details about their sampling methods and confidence levels.)

Apart from the polling itself, the way that the results are presented in the media is worth a closer look. Let's consider the data about how the bad behaviour of union officials is likely to affect support for the ALP. On various TV news programs, the data was reported in a very simplistic manner: 46% of respondents indicated that the union officials' behaviour would not influence their vote, 43% said it would, 11% unsure. On two of those TV programs, this was cast as a bad result for the Government. Really? The 46% whose votes would not change are hardly the voters we should be looking at - they represent the voters who are already polarised on their choice of party. It's the other two categories that are of interest. 43% said it would influence their vote - but in which way? If a large chunk of the 43% are voters who might vote for the ALP but who may not because of the union officials, this is good news for the government, not bad. But of course, no breakdown of the data was given.

A column in the Herald Sun gives a different set of figures (which don't seem to entirely line up with what was appearing on the news programs mentioned above), specifically:

...20 per cent of voters said they were now less inclined to vote Labor because of [union official Joe McDonald's] actions, 9 per cent said they were more inclined to vote for the party, and 67 per cent said they would not be influenced either way...

and the overall interpretation in that column was "voters also said they were largely unconcerned by the bullying actions of union officials".

Again, the columnist is looking at the largest number in the figures and drawing a conclusion from that, but the interesting numbers are the small ones - 20% of the respondents indicated that they would be less inclined to vote Labor. What proportion of those respondents would otherwise vote Labor? How significant is their change in resolve? Could this represent an increase in the proportion of swinging voters who have previously come down on the left side of the political spectrum but who may now be leaning to the right? Again, there is no breakdown and thus no way to answer these questions.

What this does illustrate is the generally poor way that polls and statistical measures are handled by the media. They are interpreted in the most simplistic terms (and some columnists are clearly happy to interpret them in line with their own political leanings). What are the viewing public to make of these statistics and the interpretations doled out by the media?

Mark Twain quipped about "lies, damn lies and statistics", a response to the spurious use of surveys and statistics by the politicians of his day. If Twain were alive today, he'd no doubt use the same line, the difference being that now newspaper columnists would figure more prominently in the list of perpetrators.

But given that news has become like takeaway food, with an emphasis on speedy delivery of something palatable without too much attention to quality, should we be surprised?

Going Back

Reversing the digits of a number is a time-honoured exercise for student programmers. It gets the student to think about integer division and modulo operations, and about iterative processes.

An exercise I've often give to my students is to write a recursive procedure for reversing an integer's digits, even though I know that it can be done more simply as a loop. This is a good way to have the students think about parameter passing and variable scope. But up till now, I've only had students doing this in Pascal.

So when I went to do it in Python, I found myself momentarily stopped by the fact that Python does not have an exact equivalent to Pascal's variable parameters. So how do I get a recursive procedure for integer reversal in Python?

I came up with two solutions.

Solution 1:

revers(n):
global q #tell Python to use the global variable, not a local one
if n > 0:
  q=q*10+n%10
  revers(n/10)
return q

q = 0
x=int(raw_input("Enter a number: "))
print revers(x)

Here, I simply made the function calculate the reversed integer in a global variable. Now, when I was learning Pascal programming, all my reference works said the same thing: don't change a global variable inside a function/procedure. Since old habits die hard, I found myself looking for a different solution to the one above, one that didn't require the global variable inside the function.

Solution 2:

revers(n,q=[0]):
if n > 0:
   q[0]=q[0]*10+n%10
   revers(n/10)
return q[0]

x=int(raw_input("Enter a number: "))
print revers(x)

This solution uses the fact that arguments to Python functions are object references, so passing a mutable object (a list being an obvious example) allows you to progressively alter the value in that object with each subsequent recursive call to the function.

Python also allows you to declare a default value for an argument and thereby omit it from the function call. The default value is evaluated only once, so setting using q=[0] as an argument only affects the first call to the function, and subsequent recursive calls do not reset the list.

As a solution, I prefer this (since it doesn't violate the rules about variable scope I learned so long ago), but I wonder how well my students will understand how the mutability of an object relates to the scope of a recursive function.

Getting Keith Backwards

I stumbled over an interesting number sequence the other day - Keith numbers (named for mathematician Mike Keith) are found as follows: starting with a number, separate the digits, then add them to form another number; continuing to sum the last n numbers in the sequence (where n is the number of digits in the original number), if the original number appears in the sequence, it is a Keith number.

For example, starting with 14, we get 1+4 = 5, 4+5=9, etc. to form the sequence 1, 4, 5, 9, 14 - since the original (14) appears in the sequence, 14 is a Keith number.

It turns out that Keith numbers are very rare (Wikipedia's article states that there are only 71 Keith numbers below 10¹⁹).

I wondered about similar number sequences, in particular numbers that produce the original number with its digits reversed. Wolfram's MathWorld site has an article on Keith numbers that also mentions these Reversed Keith numbers, but prefers the ugly term revrepfigits (and also calls Keith numbers repfigits, from 'repetitive fibonnaci-like digits').

Before I read the Wolfram MathWorld article, I had written a small Python program to find Reverse-Keith numbers (which I had decided should be called Feek numbers), and generated all the numbers up to 10 000 000.

This turns out to be a nice little programming exercise, requiring one to think about how to manage both integer reversal and splitting an integer into its separate digits prior to building the resulting number sequence. If someone wants an interesting exercise for their students, I think this is worth a look.