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.

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!

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.