“In case” vs “In the case of”

Posted on July 29, 2011 by Paul Hartzer

I’ve been noticing increasingly frequent use of “in case” in situations where “in the case of” would be warranted. I think this is largely attributable to signs such as “In case of fire, take stairs” and “In case of fire, break glass”. These signs are examples of telegraphic speech; space and reading time are at a premium but a formal register is called for (more on that below). If there were room, the signs would read “In the case of a fire, take the stairs” and “In the case of a fire, break the glass”. The articles are dropped out to make the signs easier to produce in a legible font and easier to read quickly.

However, because “in the case of” and “in case” are semantically similar and easy to confuse, it seems that people are indeed starting to confuse them. This is unfortunate, because the two phrases serve complementary purposes.

When used as intended, “in case” indicates that the condition that’s supplied is likely or at least plausible, but is not currently happening. “Take an umbrella in case it rains” very strongly implies that it’s not currently raining. Perhaps it’s overcast, perhaps the weather report called for scattered showers, perhaps it’s London or Seattle, but in any event it’s not currently raining. “In case of fire, take the stairs” in a non-telegraphic context (hence the article in the independent clause) would be an instruction to avoid the elevator at all times, because you never do know when a fire might break out. Heavens forbid that you’re stuck inside an elevator when a fire breaks out! Take the stairs!

“In the case of”, on the other hand, indicates that the condition that’s supplied is currently happening. “Use an umbrella in the case of rain” is a directive to use the umbrella when it’s raining (and, by conversational implicature, only when it’s raining).

“In the case of” is also a fairly stilted phrase. In casual speech, it’s more natural to say “If there’s”. “In the case of a fire, take the stairs” could be more comfortably phrased as “If there’s a fire, take the stairs”. As I say above, though, that lacks the formal register tone that we expect from warning signs. So even though “If there’s fire, take stairs” takes fewer characters, is less telegraphic, and avoids the ambiguity at hand, it’s eschewed in such contexts.

Note that this is more significant than the ambiguity involving “take”. “Take the stairs” could logically mean ”use the stairs to move between levels of a building”, “relocate the stairs out of this area”, or “establish a base or blocade on the stairs to prevent an opponent from using them”. Naturally, though, the uses of the last two meanings are so rare as to not create a communicative problem except in those rare situations (such as, for instance, playing war games as a corporate bonding exercise).

On the other hand, as the example of “take an umbrella in case of rain”/”use an umbrella in the case of rain” shows, the ambiguity in this situation can indeed lead to communication problems. Consider, “I’m going to send you to your room, in case you talk back to me!” A parent issuing such a directive probably means to warn the child (if you talk back to me, you’re going to your room), but technically what is said is “Because there’s a plausibility that you’re going to talk back to me in the near future, I’m now going to send you to your room!” An appropriate reaction becomes an inappropriate preemption. This is a very important distinction.

Posted in English | Leave a comment

Slitherlink programs for Android

Posted on July 3, 2011 by Paul Hartzer

Introduction

I recently acquired an Android-based phone to replace my WebOS Palm Pré. One thing I’ve been looking forward to on the Android was getting the opportunity to develop apps that I could run myself, and that might have a reasonable sized audience. Since I have logic already for creating Hitori, Slitherlink, and Battleships puzzles, I thought one of those three would be the best option for a first Android app. To be done right, though, Battleships would need some graphics.

The market has made my decision between developing Hitori or Slitherlink. I can only find one Hitori app on either the Android marketplace or the Amazon store, and that one is buggy: It creates grids with multiple solutions (while only recognizing one as correct), and there’s an odd problem with the first cell in the second row getting deselected in certain circumstances.

For Slitherlink, meanwhile, there are several apps; I tried out three, one of which shines above the other two. Here they are, in reverse order of my preference. So, while my first Android app is going to be a port of Hitori, I’ll have some Slitherlink puzzles to play with.

#3: Loopy, part of Simon Tatham’s Puzzles (free)

Simon Tatham’s Portable Puzzle Collection is a wonderful set of 33 puzzles, most of them of the logic-grid variety. The problem is, the Android port for some of the puzzles, such as Loopy (Simon Tatham’s name for Slitherlink) is not very friendly for tiny smartphone touchscreens which lack D-pads, such as my Samsung Replenish. I tried a small square-based puzzle, and found it far too frustrating trying to click on the links. I could not figure out how to zoom.

On a larger screen Android device, such as a tablet, I’m sure Loopy is just fine. It appears to be a perfectly authentic port of the desktop version, including all eight grid types. However, on my smartphone, it’s nearly unusable.

#2. Tatsuyo Kaido’s SlitherLink Plus (free/$3.71)

In this set, all puzzles were generated and tested by humans, as opposed to being computer-generated; the notes claim that computer-generated puzzles can sometimes have multiple solutions, and be overall less satisfying. While I have yet to have Loopy create a puzzle with multiple solutions, I do admit that some of Loopy’s puzzles seem artificial. I think perhaps the key is that, ideally, Slitherlink puzzles ought to be tested by humans; certainly, though, a computer algorithm for creating unique-solution puzzles should be more (not less) reliable than a human.

At any rate, this is a satisfying enough version of Slitherlink. It has a zoom function for those of us with wide fingers and small screens. There are three features of my first choice that makes it superior to Tatsuyo Kaido’s, which I’ll discuss below, but if SlitherLink Plus were the only Android app available, the world would still be wonderful.

#1. Ejelta’s Slitherlink (free/$1.99)

This is my favorite, with several features that make it an absolute joy.

First, zoom is done by pinching; Tatsuyo Kaido’s accomplishes this with buttons at the bottom of the screen. I find the pinch-zoom to be a much more convenient method.

Second, while Tatsuyo Kaido’s only has square-cell puzzles, this features four types (all among Loopy’s eight): Squares, Honeycombs, Cairo, and Kites. There are three difficulty levels and four grid sizes.

Finally (as a default option), each connected line segment is shown in a different color. This is a great solving aid, as the solver can tell in a zoomed area whether two line endings are part of the same loop. As segments are connected together, one of the colors is chosen and applied to the entire (new) line.

The number clues change color when they’ve been satisfied, although this option can be turned off. Edges which are illegal (because they exceed the clue numbers, they close a non-inclusive loop, or they connect three lines to the same point) are marked in red; I couldn’t figure out how to turn this feature off.

The solver doesn’t have to finish one puzzle before starting another; all partially completed puzzles are available at the bottom of the home menu, and saved automatically.

Purists may object that the clues aren’t symmetrically distributed. I don’t mind, personally, but it may be important to others. Also, I would have liked a check feature that lets you know whether you have errors (see, for example, BrainBasher’s version).

However, overall, I find the program to be excellently designed and presented, and highly recommend it to Slitherlink fans.

Posted in Hitori, Slitherlink | Leave a comment

Divisible by 7: An easier algorithm

Posted on June 14, 2011 by Paul Hartzer

In an earlier post, I discussed an algorithm for determining if a number is divisible by 7. James Chegwidden shared a simpler algorithm: Strip the leftmost digit, multiply by 2, and subtract from the rest. Repeat until you get a number you recognize as a multiple of 7.

For instance, take 43,669,668, which is 6,238,524 · 7. Applying the algorithm, we get:

  1. 4366966 – 16 = 4366950
  2. 436695 – 0 = 436695
  3. 43669 – 10 = 43659
  4. 4365 – 18 = 4347
  5. 434 – 14 = 420
  6. 42 – 0 = 42
  7. 4 – 4 = 0

Since our final answer is in {7, 0, -7}, the original number is divisible by 7.

Cool… but why?

Consider the algorithm algebraically. We assume that some number x is divisible by 7, meaning:

  • x = 7a

Where a is an integer. The algorithm says to remove the last digit, double it, and subtract. That is,

  • (x – c)/10 – 2c = 7b

where c = x mod 10; this can be simplified to:

  • (x – c) – 20c/10 = (x – 21c)/10 = 7b

If x is divisible by 7, then (x – 21c) will be divisible by 7. Also, x – c is divisible by 10. Hence, x is divisible by 7 if and only if (x – c)/10 – 2c is divisible by 7.

By the same general principle, note that 1001 is also a multiple of 7. That means that as a first step for large numbers, we can first break it into groups of three and alternate adding and subtracting. For instance, consider 43,669,668 again. First, write the groups of three in reverse order. Then apply the algorithm above to the result:

  1. 668 – 669 + 43 = 42
  2. 42 yields 4 – 4 = 0

Thus, 43,669,668 is divisible by 7.

Posted in Algebra | Leave a comment

ROUND and MOD: Inconsistencies in Excel

Posted on June 8, 2011 by Paul Hartzer

Quick question: What is 2.5 rounded to an integer? Here’s another: What’s the value of 3.3 mod 1?

I’ll make it easier. What is the answer to each question in Microsoft Excel?

The answer to each question is, it depends on whether you’re talking about Excel formulas or Excel VBA.

The story behind rounding is at least an interesting one, so I’ll start with the short and merely strange case of mod. In an Excel formula, x mod y treats the variables as real numbers ℝ (that is, as doubles), while VBA treats them as integer numbers (members of ℤ). Hence, =mod(3.3,1) results in 0.3, while Debug.Print 3.3 Mod 1 yields 0. Since the Mod worksheet function is not available to VBA (see below for Round), the only way to duplicate the real number version is to use a formula such as x - Int(x).

There’s also a difference in how negatives are treated. The Excel formula loses the sign, so that =mod(-3.3,2) results in 0.7. Note that it’s not the mod of the absolute value, but rather the distance from the input value to the next lowest qualifying value (that is, the result of x – Int(x)). Excel VBA maintains the sign, so that Debug.Print -3.3 Mod 2 returns -1.

Rounding, at least, has an interesting story behind the inconsistency. There are two basic kinds of rounding: Arithmetic rounding and banker’s rounding. In both cases, numbers other than i + 0.5 are rounded to the nearest integer (assuming, of course, we’re rounding to 0 decimal places). The difference is in how 0.5 is treated.

Arithmetic rounding, by convention, rounds i + 0.5 up to i + 1 (so 0.5 is rounded to 1, 1.5 to 2, and so on). The problem with this, from a banking perspective, is that it means that numbers get rounded up more often than they get rounded down. If you’re rounding from one decimal point to zero points, it means that 5/9ths of the rounding is done up, which can lead to a lot of extra pennies.

Banker’s rounding, by convention, rounds i + 0.5 to the nearest even number, so 0.5 is rounded to 0, 1.5 and 2.5 to 2, and so on. That means that rounding goes up exactly half the time. The pennies are saved!

Excel formulas use arithmetic rounding, while VBA uses banker’s rounding. This strikes me as counterintuitive, given Excel’s main history as accounting software. However, it is what it is. At least in this case, arithmetic rounding is available to VBA (although banker’s rounding in a formula requires a bit more creativity). Specifically, Debug.Print Round(2.5) returns 2, while Debug.Print Application.WorksheetFunction.Round(2.5, 0) returns 3.

Microsoft’s documentation notes the discrepancy with the rounding (although I haven’t found similar documenting on the discrepancy with mod), and cites “historical reasons.”  It makes sense, for backwards compatibility, that they wouldn’t want to change the existing functions. It does however strike me as odd that Microsoft has chosen thus far not to correct it by adding new functions (e.g., by adding BROUND() as an Excel formula function). Even stranger is that Mod seems to have been explicitly and deliberately left off the worksheet functions available to VBA, which suggests that Microsoft programmers aren’t even aware of that discrepancy.

These are the sorts of tiny landmines that make Microsoft Office so… engaging to work with.

Posted in Excel | Leave a comment

Divisible by 7: As, uh, easy as 1, 3, 2

Posted on May 21, 2011 by Paul Hartzer

Introduction

When I was a lad, I was taught how to quickly determine if a multiple digit number is divisible by any single digit integer, except 7. Here are the other rules:

  • 1: Trivial. Everything is divisible by 1.
  • 2: Any even number (i.e., any number ending in 2, 4, 6, 8, or 0) is divisible by 2.
  • 3: If the sum of a number’s digits are divisible by 3, the number is divisible by 3. This is recursive. For instance, assume you’re considering 3,456. 3 + 4 + 5 + 6 = 18; 1 + 8 = 9. Since 9 is divisible by 3, so are 18 (9·3) and 3,456 (1,152·3).
  • 4: This was taught to me as: Any number whose last two digits are divisible by 4 is divisible by 4. This is because 100 is divisible by 4; therefore, any three- or more digit number x is of the form 100a + x0, where 0 ≤ x0 < 100. However, a variation of this rule that relies on only considering digits individually is: If the penultimate (that is, the second-to-last) number is odd and the final digit is an even multiple of an odd number (2 or 6), or the penultimate number is even and the final digit is an even multiple of an even number (0, 4, or 8), the number is divisible by 4.
  • 5: If a number ends in 0 or 5, the number is divisible by 5.
  • 6: If a number is divisible by both 2 and 3, it’s divisible by 6.
  • 7: See below.
  • 8: This is the second trickiest. This was taught to me as any number whose last three digits is divisible by 8 is divisible by 8; this is because 1000 is divisible by 8. There’s a variation that involves treating digits individually, which I’ll provide below as a foundation for the method for 7.
  • 9: If a number’s digits add up to a multiple of 9, then the number itself is divisible by 9.

An algorithm for 8

So let’s look at 8, first. Here are the multiples of 8 from 1 to 100:

  • 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96.

As the tens place goes up 1, the ones place goes down 2. Let’s multiply the tens place by 2 and add it to the ones place. That gives us this series:

  • 8, 8, 8, 8, 8, 16, 16, 16, 16, 16, 24, 24.

If we were to repeat that, we’d have 8s all the way. Now let’s consider the multiples of 8 from 100 to 200:

  • 104, 112, 120, 128, 136, 144, 152, 160, 168, 176, 184, 192, 200

Notice that since 200 is divisible by 8, we could take the modulus of the longer number by 200, following the original rule for 4 (mod 100). However, there’s another pattern. Just as we could multiply the penultimate digit by 2, we can multiply the antepenultimate (that is, the third-to-last) digit by 4. Applying that rule to the series above gives us:

  • 8, 8 (that is, 4·1 + 2·1 + 2), 8 (4·1 + 2·2 + 0), 16, 16, 16, 16, 16, 24, 24, 24, 24, 8

Hence, as a general rule:

  • 8: Given any integer, consider only its last three digits, abc. If 4a + 2b + c is divisible by 8, then the entire number is divisible by 8.

This is because 100 is 4 greater than 96, which is divisible by 8, and 10 is 2 greater than 8, which is divisible by 8. That is to say, we’re treating the last three digits as an algebraic function, and removing the parts we know are divisible by 8.

Again, consider the last three digits of a number, abc. Since we’re working in base 10, a three-digit number abc = 100a + 10b + c. Since 96 is a multiple of 8, then 96a will be a multiple of 8; likewise, 8b will be a multiple of 8. That is:

  • 100a + 10b + c = 96a + 4a + 8b + 2b + c
  • = (96a + 8b) + 4a + 2b + c
  • = 8(12a + b) + 4a + 2b + c

Hence, if 100a + 10b + c is a multiple of 8, so too will be 4a + 2b + c.

An algorithm for 7

Now, how does that help us with 7?

When we apply the same basic strategy, we come up with a more complex pattern. Take each factor of 10n:

  • 1 = 0 + 1 = 7·0 + 1
  • 10 = 7 + 3 = 7·1 + 3
  • 100 = 98 + 2 = 7·14 + 2
  • 1,000 = 1,001 – 1 = 7·143 – 1
  • 10,000 = 10,003 – 3 = 7·1,429 – 3
  • 100,000 = 100,002 – 2 = 7·14,286 – 2
  • 1,000,000 = 999,999 + 1 = 7·142,857 + 1
  • 10,000,000 = 9,999,998 + 3 = 7·1,428,571 + 3

… and so on. A simple pattern emerges: 1, 3, 2, -1, -3, -2, 1, 3. This pattern holds up ad infinitum.

We can apply this pattern to an integer of any length. Take 37,886,198, for example (and note that, because the pattern requires digit triplets, it’s useful to keep the commas). Apply the pattern (reversing its order):

  • 3·3 + 7·1 – 8·2 – 8·3 – 6·1 + 1·2 + 9·3 + 8·1
  • = 9 + 7 – 16 – 24 – 6 + 2 + 27 + 8
  • = 7

Conclusion

It’s a very fair criticism that this method involves more computation than simply dividing the long number by 7. Indeed, it does. The methods listed above for the other digits are simple; even the rule for 8 is a veritable cakewalk compared to this. I imagine it’s why, when my elementary math teacher was giving us the other shortcuts, he muttered something disparaging about 7 and went on to other topics.

However, I think the method does illustrate a very important aspect of our number place system: An integer expressed as abcdefB, where each letter represents a digit and B is the base, is equal to B5a + B4b + B3c + B2d + Be + f. If conditions dictate, we can use this to algebraically manipulate the integer. So while the algorithm for 7 is generally too onerous to be useful, it demonstrates an important mathematical concept.

Notice, by the way, that the same concept underlies all the other rules, albeit in those cases it results in much simpler rules:

  • 1: Trivial. Since 10 is divisible by 1, you only need to consider the last digit, which is always divisible by 1.
  • 2: Since 10 is divisible by 2, you only need to consider the last digit.
  • 3: All powers of 10 are one greater than a multiple of 3 (10 = 9 + 1, 100 = 99 + 1, 1,000 = 999 + 1).
  • 4: Since 100 is divisible by 4, you only need to consider the last two digits. See the discussion above for both 4 and 8.
  • 5: Since 10 is divisible by 5, you only need to consider the last digit.
  • 6: Since 6 = 2·3, any number divisible by both 2 and 3 is divisible by 6.
  • 7: See the discussion above.
  • 8: See the discussion above.
  • 9: All powers of 10 are one greater than a multiple of 9 (10 = 9 + 1, 100 = 99 + 1, 1,000 = 999 + 1).

Also notice that, in base 8, determining if an integer is divisible by 7 is as easy as determining if a number in base 10 is divisible by 9: Add up the digits. Here are the first multiples of 7 in base 8:

  • 7, 16, 25, 34, 43, 52, 61, 70, 77, 106, 115, 124, 133, 142, 151, 160, 167, 176, 205

Remember that these numbers are in base 8, so 77 yields 7 + 7 = 16, not 14; in turn, 1 + 6 = 7. The general rule: If a number in base B is divisible by B-1, the sum of the digits will also be a multiple of B-1.

Posted in Algebra | 1 Comment

Łukasiewicz, er, Polish Notation

Posted on April 29, 2011 by Paul Hartzer

Okay, so, eponyms are common throughout math: Cartesian coordinates, Fibonacci sequences, Pythagorean triangles, Curried functions, Łukasiewicz notation… oh wait, I guess people decided that last one was just too difficult, so it’s “Polish notation.” That actually strikes me as vaguely bigoted, since (1) Łukasiewicz (wook-a-SHAY-vich) isn’t that difficult to say and (2) when he was born, it was in Austria-Hungary, and the city (L’viv) is now in Ukraine. He was ethnically Polish, though. Anyway. I might just start calling it Łukasiewicz Notation to be a troublemaker. It’s not like it’s in common usage anyway.

For those who wonder what I’m on about in the first place, Łukasiewicz Notation (more commonly known as Polish Notation) involves placing the operators in front of the operands instead of between them. This resolves ambiguity. For instance, consider 6/2(1+2), which is one of those annoying questions going around on Facebook. Traditional operation order (Please Excuse Me Dear Aunt Sally, if you will) says that you evaluate the part in the parens first, then go from left-to-right with the same order operators. Hence, 6/2(1+2) = 6/2(3) = 3×3 = 9. However, the way it’s written, the formula looks like you should multiply first, that is, 6/2(1+2) = 6/2(3) = 6/6 = 1.

There’s no such problem in Łukasiewicz Notation. These are different:

  • 9 = * / 6 2 + 1 2
  • 1 = / 6 * 2 + 1 2

Łukasiewicz Notation is used in some programming languages, although nothing you’re likely to use unless you’re a serious hobbyist. The conceptual advantage is that it’s very straightforward to parse just like any other formula, particularly if the operators are restricted to binary interpretations. The parsing is done thus: When an operator is encountered, add it to the “operator” stack. When a value is encountered, attach it to the operator on the top of the stack; if that fills the operator’s needs, evaluate, and use the return value to assess the next operator on the stack.

In this case, consider * / 6 2 + 1 2. It’s parsed like this:

  • * is a binary operator, that is, it takes two values. Put it on the stack: *(?,?) (the question marks indicate the values that we’re still looking for).
  • / is a binary operator. Put it on the stack. That stack is now: /(?,?) *(?,?).
  • 6 is a value. / has one of its values now. The stack is now: /(6,?) *(?,?).
  • 2 is a value. / has both of its values now. Evaluate /(6,2) = 3.
  • 3 is a value. * has one of its values now: *(3,?).
  • + is an operator. The stack is now: +(?,?) *(3,?)
  • 1 is a value. The stack: +(1,?) *(3,?)
  • 2 is a value. Evaluate +(1,2) to 3. Evaluate *(3,3) to 9. The stack is empty, so we’re done.

In other words, Łukasiewicz notation treats the mathematical operators like any other function, which is what they are. Parentheses are only needed if there’s no restriction that the operators be binary. That is, either of these are legitimate, and equal 6:

  • + + 1 2 3
  • + (1 2 3)

I prefer the former, although in some cases (such as Excel’s AND and OR operators, which are functions that take any number of arguments two or greater), I can see the attraction of the latter.

Posted in Math, Programming | Leave a comment

Get Variables in Access

Posted on April 23, 2011 by Paul Hartzer

An early challenge at my current position was to find a way to access VBA variables in queries. This was in response to the common method of just using hidden fields on the form; I developed a parameters table, which I now include in all my Access projects. The parameters table has some key advantages.

One is that it allows for persistence of variable values across sessions. For instance, in one case, the user loads files of sort A from directory A, sort B from directory B, and so on. By storing each directory in a parameters table, the database can open the correct directory for each sort of file.

Another is that the form on which the variable is set doesn’t need to be open for the variable to be used. This is a drawback of form variables. This advantage can be especially useful during debugging.

However, I recently ran into a limitation. My previous Access projects have been designed with a single end user in mind. I’m currently working on a project intended for a team of several people. Because the users will be loading data from different sources and from different clients, I decided to have a parameter row for each user.

When the database opens up and the Dashboard form loads, the first thing the code does is retrieve the user’s network identifier and looks it up on the user list. If it’s not found, the database asks the user for their name so it can be inserted on the table; the network identifiers at work are random and have no connection to the user’s name. In addition to creating a record on the user name table, the code also creates a record on the parameters table for that user.

This is where I ran into trouble: I had need to filter some of the queries by the user name. Since it was possible that multiple users could be using the database at the same time, I couldn’t set up a separate parameter table to hold the current user’s ID. I had to find a way to get the user ID from the code to the query, and I still resisted the notion of using a hidden form variable.

I tried something that I didn’t think would work, and later I realized I should have done it long ago. While Access SQL can’t directly reference global variables in VBA code, it can run functions, as long as those functions are public and stored in standard modules (that is, not in the code for the form or report, which is treated as a class module).

Theoretically, this means I could simply use fOSUserName() in SQL code, as in:

Select ClientName from tblClients where ClientID =
(Select ClientID from tblParameters where UserID =
fOSUserName());

This would work for this scenario, but the general idea can be expanded for any global variable in the VBA code. In practice, since I was initially not sure how much overhead the fOSUserName code used, I decided to only call it once and store its value in UserName. I then created a second function, which should be readily recognizable to most programmer sorts as a getter function:

Function GetUserName() as String
    GetUserName = UserName
End Function

This method has the added advantage that, if I decide later (or am later requested) to store the user’s name instead of their network ID, it’s straightforward to change the code; I simply change the UserName assignment. Again, the key is that the GetUserName() function has to be in a standard module (I call mine modAdmin), not in a class module (including form and report code).

Using a parameters table along side getter functions allows for passing any variable information collected in the VBA portion to be passed to SQL queries.

Posted in Access | Leave a comment

Metric paper sizes

Posted on April 21, 2011 by Paul Hartzer

Ever since I was made aware of the European paper sizes, I’ve wondered about them. In general, the world outside of North America prefers metric, but A4 paper superficially appears to have no connection to the metric system. It measures roughly 210mm by 297mm, or 8.27″ by 11.69″. What gives? I would have expected something like 200mm by 300mm, something nice and tidy and yet not too far off from the North American standard of 8.5″ x 11″.

Lately, I’ve been reading math articles on Wikipedia in German, French, and Spanish, because that’s how I roll. (My primary goal is to develop my math lexicon in Spanish, but I gravitate back to German and French because they’re easier for me to read. But I digress.) Today I was reading about the square root of two on Wikipedia France, which includes a section on paper sizes.

It turns out that the ISO for paper sizes sought to establish two characteristics of the base paper size, A0:

  • When cut in half, each half had to have the same aspect ratio as the total.
  • A0 had to have a total area of 1m2.

These two characteristics together make for the strange paper sizes.

Let’s say we have a rectangle, R0, with length L0 and width W0. We cut this in half, creating two copies of R1 with length L1 and width W1. Additionally, W1/L1 = W0/L0 (from the requirement that they have the same aspect ratio).

Because we cut R0 in half, it follows that W1 = L0/2 and that L1 = W0. Hence, W0/L0 = L0/2W0. Multiplying by the denominators gives us 2W02 = L02, or W0 = L0/√2.

The area of R0 is L0W0, hence L02/√2. Since the area of R0 is 1m2, L02 = √2, and L0 = √√2, that is, 4√2, or ~1.1892m. W0 is 4√2/√2, or ~0.8409m.

All this math does have its advantages. Because every A paper size is half of the next larger one, it makes scaling and designing booklets straightforward; the B and C series sizes (also geometrically related to the A sizes) allow for appropriately sized envelopes. An added bonus is that, if you have A4 paper and a C5 envelope, you know you need to fold the A4 paper in half and it’ll fit perfectly; with a C6 envelope, you need to fold the paper in half and then half again. No surprises.

Even so, the sizes do make for some odd looking numbers when separated from the metric origins.

Posted in Geometry | Leave a comment

Visual proof of the Pythagorean Theorem

Posted on April 20, 2011 by Paul Hartzer

This is an extended version of my presentation for the Woodrow Wilson Teaching Fellowship.

The Pythagorean Theorem states that, given the lengths of any two sides of a right triangle, it is possible to determine the length of the third side. It is a specific form of the general notion that, given any three pieces of information about a triangle (in this case, one angle and two sides), it is possible to determine all three sides and all three angles.

In the specific case of a right triangle, the formula is a2 + b2 = c2, where c is the hypotenuse. This formula is particularly useful when calculating distances on a grid, since it allows us to determine how far a point is from the origin if we know its x and y coordinates.

To prove the theorem visually, let’s start with a right triangle (images created by GeoGebra, free geometry software). In this case, the sides are 3 and 4 units long. Following the theorem, that means that c1 is 5 units long:

32 + 42 = 9 + 16 = 25 = 52

To prove this visually, imagine we arrange four copies of the triangle to form a four-sided polygon. We can prove that this polygon is a square, and then we can demonstrate that its area is 25.

Proving that ABDF is a square involves two statements. First, all of the sides have the same length, since the triangles are identical. Second, we have to demonstrate that all of the corners are right angles:

α1 + β1 + γ1 = 180º
γ1 = 90º
∴ α1 + β1 = 90°
α1 = α2
∴ α2 + β1 = 90°

This can be repeated for all corners. Hence, ABDF is a square.

What is the area of ABDF? It consists of five shapes: Four triangles and a square.

Each triangle has a length of 3 and a height of 4, giving it an area of half of the length times width, that is, 3 x 4 / 2 = 12 /2 = 6. Since there are four such triangles, they contribute a total of 6 x 4 or 24 units.

Let’s look now at the square CEGH. BC is 4 units long, and BE is 3 units long. Therefore EC is one unit long. So CEGH is one unit square, contributing 1 unit to ABDF. 24 + 1 = a total volume of 25, as expected.

We can generalize this method as follows.

  1. Given a right triangle with sides a and b, the four identical triangles will contribute a volume of 4(ab/2) or 2ab to the external square, ABDF.
  2. The internal square will have sides of (a – b) (where a is larger), and hence an area of (a – b)2. We can expand this to a2 – 2ab + b2.
  3. Adding the area of the four triangles to this gives us a2 – 2ab + b2 + 2ab, that is, a2 + b2 as the area of the larger square.
  4. Since the area of the larger square is c2, we have derived the Pythagorean theorem.

Armed with this, you can now prove the theorem on a cocktail napkin at your next party.

Posted in Geometry | 2 Comments

A Month of Sundays

Posted on April 19, 2011 by Paul Hartzer

At my current work place, data is collected daily, reported on weekly, and summarized monthly. The client wants a monthly report to consist of an aggregate of weekly reports, rather than a new compilation of data observations from a calendar month. Specifically, the week runs from Sunday to Saturday, and a month consists of those weeks that have workdays in that month rather than the neighboring month.

If a month starts on a Sunday (as May will), this is straightforward: The week falls entirely within the month. Likewise, if a month starts on a Monday (as August will), there will be no data from the last day of the previous month (a Sunday) regardless. If a month starts on a Saturday (as January did), the first of the month is irrelevant since it’s not a work day. However, if a month starts on a Tuesday, Wednesday, Thursday, or Friday (as most months do), there will be days assigned to a different month based on the week than the calendar dictates.

This was explained to me in a fairly complicated way, as if the only way to figure this out reliably is to consult the table provided by the client. Indeed, I was provided with such a list, which I used to set up an earlier database project.

For the current project, however, I decided to explore how to calculate this. I had two practical reasons: Referring to a table means the table has to updated each year, and while the other project only involved data that had already been assigned to a week (that is, it was loaded with a “week” field), the new project contained data with days, rather than weeks, indicated. This meant the table would have to have nearly 52 x 5 or 260 entries per year, rather than “only” 52.

I had the additional motivation of proving I could.

When I thought about it, I realized the main problem was much easier than it had been presented to me: To determine what month a week belongs to, look at the Wednesday. That’s it. If a month starts on a Tuesday or a Wednesday, then at least three of the standard work days will fall in that week. Even when work days are taken up by holidays, there doesn’t appear to be a situation where this would fail; for instance, if January 1 is on a Wednesday, then January will only have two standard work days (the 2nd and the 3rd), but December 31 is very often a holiday, or at least a half day.

In Excel, the formula for determining a month is this simple:

=MONTH(A1+4-WEEKDAY(A1))

Excel assumes any calculation involving dates will involving adding or subtracting days, unless specifically told otherwise. Access needs it to be explicit:

Month(DateAdd("d",4 - Weekday([FieldName]), [FieldName]))

This uses several shorthand functions; you could also write it this way:

DatePart("m", DateAdd("d", 4 - DatePart("w", [FieldName]), [FieldName]))

“m” represents the month of the specified date, “d” the date, and “w” the weekday (where Sunday is 1).

Personally, I prefer the Excel formula for readability, but the idea is the same: To a date, adjust to Wednesday by adding four and subtracting the day’s ordinal placement in the week. For instance, since Monday is day 2, you’ll be adding 4 – 2 or two days to the date. Since Thursday is day 5, you’ll be adding 4 – 5, that is, you’ll be subtracting one day.

I then took the next step, which is more complicated. I wanted to create a function that would return an array filled with the dates in a given month. This is the function I came up with:

Function GetSundays() as Date()

    Dim FirstDayOfMonth As Date, MonthNumber As Long
    Dim FirstDayOfNextMonth As Date
    MonthNumber = DLookup("ReportMonth", "tblParameters")
    Dim SundaySet() As Date, SundayIndex As Long

    FirstDayOfMonth = DateSerial(ReportYear, MonthNumber, 1)
    If MonthNumber = 12 _
        Then FirstDayOfNextMonth = DateSerial(ReportYear + 1, 1, 1) _
        Else FirstDayOfNextMonth = DateSerial(ReportYear, MonthNumber + 1, 1)

    Dim IterateDate As Date
    SundayIndex = 0
    For IterateDate = FirstDayOfMonth - 3 To FirstDayOfNextMonth - 4
        If Weekday(IterateDate) = 1 Then
            ReDim Preserve SundaySet(SundayIndex)
            SundaySet(SundayIndex) = IterateDate
            SundayIndex = SundayIndex + 1
        End If
    Next IterateDate

    GetSundays = SundaySet

End Function

There are no doubt some improvements that could be made on the code. Also notice that ReportYear is a global constant while ReportMonth is saved on a parameters table; this is not ideal.

However, I think this example serves to illustrate the relative simplicity of the solution. Note the same basic concept is used: Because Wednesday is used as the determiner of the month, the loop runs from three days before the first day of the current month (which, if the first day is a Wednesday, would be a Sunday) to four days before the first day of the next month (which, if the first day is a Wednesday, would be a Saturday).

This function returns an array of either four or five elements, depending on the input month and year selected. This is the subroutine I wrote to test it:

Sub tryit()
    Dim SundayList() As Date
    SundayList = GetSundays
    Dim Iterate As Long
    For Iterate = 0 To UBound(SundayList)
        Debug.Print SundayList(Iterate)
    Next Iterate
End Sub

It works perfectly.

Posted in Access, Excel | Leave a comment