Displaying the five most recent posts.

## Calendrical Calculations, Part 1: Cyclical vs. Linear

By some accident of probability, I have exactly eight nieces and no nephews. The fact that they're all nieces isn't relevant to the story; it's just interesting. The fact that there are eight of them is relevant.

So, it's my job as the bachelor uncle to buy the cool toys for my nieces on their birthdays. Since there are eight of them, I'm going to need help remembering their birthdates. Yes, I know that they have calendars and apps for your phone that will tell you these sorts of things, but I want us to understand how those apps work.

First, I e-mail my sister in Mexico, Helena, and my sister-in-law across town, Susan, to get a list of all the birthdates in their families. I'm going to compile their responses into a table of some sort.

Amy 10/15/10 23.9.2007 30.3.2013 9/17/12 March 4, 1986 31.5.2015 4/2/14 3.10.1982 6.5.2002 October 6, 1955 April 14, 1956 6/22/84 5/28/15 22.5.1981 1/22/85

Yuck. The dates don't look the same. Helena lives in Mexico, so, as one would expect, she provided the dates with the day of the month first, the month next and the year last. Susan, on the other hand living in the United States, gave me the dates in the American format: the month, followed by the day of the month and then followed by the year. Helena used four-digit years while Susan gave me two-digit years. I myself entered in a few birthdates for family members that I already knew, but I spelled out the months. When I got the responses, I just threw them onto a table the same way that I got them. They need to be consistent.

Let's try putting them all in my format.

Amy October 15, 2010 September 23, 2007 March 30, 2013 September 17, 2012 March 4, 1986 May 31, 2015 April 2, 2014 October 3, 1982 May 6, 2002 October 6, 1955 April 14, 1956 June 22, 1984 May 28, 2015 May 22, 1981 January 22, 1985

Now, it's sorted alphabetically by name. Here's the thing: I need to know who's birthday is coming up next. If the list were in order by birthday, I may be able to figure this out better. Let's tell the computer to sort it that way.

Lucy April 14, 1956 April 2, 2014 January 22, 1985 June 22, 1984 March 30, 2013 March 4, 1986 May 22, 1981 May 28, 2015 May 31, 2015 May 6, 2002 October 15, 2010 October 3, 1982 October 6, 1955 September 17, 2012 September 23, 2007

That didn't turn out the way that I expected it. It sorted it alphabetically by month. Also, it didn't even sort properly within the month. Look at the month of May: Samuel, Patricia and Elisa's birthdays seem to fall in order. However, Juliana's birthday is before any of theirs, but she's listed after. That's because ‘6’ comes after ‘2’ and ‘3’ when we sort alphabetically. We need to make these numbers somehow.

At my work, when we enter in dates into the computer system, we enter a two-digit month, a two-digit day of the month and then a two-digit year. For example, today, 2018 September 16 would be entered in as “091618”. Let's try entering the dates with this method and then sorting on that.

 Susan 012285 030486 033013 040214 041456 050602 052281 052815 053115 062284 091712 092307 100382 100655 101510

Yes, this really is how we enter the dates into the computer at work, and it's a bad way to do it. At least now, they're in the order that I want. Also, Catherine's having a birthday tomorrow! I need to get her a gift tonight! Before I can do that, I need to know how old she's going to be. Of course, I could just look at the number and deduce that she'll be six, but I need to get the computer to figure that out. Actually, what will be helpful would be to sort the list in such a way where the oldest people are on top and the youngest on the bottom. To do that, I need to change the date format again.

 Lance 19551006 19560414 19810522 19821003 19840622 19850122 19860304 20020506 20070923 20101015 20120917 20130330 20140402 20150528 20150531

Okay, we have a four-digit year, two-digit month and two-digit day of the month. This is still a bad way to do it in my opinion. However, there are computer systems that use this method. MySQL uses a similar method for storing its dates. Why is this bad then?

Let's take a moment to talk about time in the platonic sense. Not only do we perceive time in cycles, we order our lives around these cycles as well. Think of how often you wake up, attend religious ceremonies, get paid, pay the rent or the mortgage, pay taxes, vote or watch the Olympics. All of these events occur in cycles. The day is probably the most fundamental of these cycles, but even the day is broken up into smaller cycles. An analogue clock is the absolute perfect way to represent this. The instant that the second hand reaches the top of the clock, a new cycle of sixty seconds begins, and the number of these cycles that have passed is represented by the minute hand (and, similarly, the hour hand). Since we perceive time in cycles, it is natural that we represent time that way in our speech and our writing.

However, it is exactly deplorable to do mathematical calculations when time is represented in cycles. (It's possible… but it's also exactly deplorable.)

When dates get represented as numbers, they need to act like numbers. For example, if I'm travelling on the highway and if I'm at mile marker 269 and if I know my destination is at mile marker 116, I can easily subtract the two numbers to know that my destination is 153 miles away. This makes sense because… that's… just how numbers work!

Suppose that I want to know how much older Patricia is than Elisa. Using the numbers on our table, we can subtract Elisa's birthday (20150531) from Patricia's birthday (20150528). Doing the math tells us that Patricia is three days older than Elisa. Perfect right?

No! Let's try that again, except, let's see how much older Lance is than Nicholas. By doing the same subtraction, we get 289,616 days—which is close to 793 years. I happen to know that Lance was twenty-eight when Nicholas was born. Why did the math work for Patricia and Elisa but not for Lance and Nicholas? It's because Patricia and Elisa were both born in the same month—May of 2015. Lance and Nicholas weren't. This system has gaps in it—literally. For instance, the difference between 20171231 and 20180101 is only one day. However, if we subtract the two numbers, we get 8,870 and not… one (you know, kind of like we should). Also, what about a date like 20171581? That's not even a date that ever existed, but what would a computer program even do if it was given that input?

We want the dates to work the same way that our mile markers worked. In order to get that to happen, we have to abandon notating our dates in cycles and put them on a linear scale like the mile markers. (I do have to point out that the mile-marker analogy breaks down as soon as we realize that the mile markers reset at the state line.)

This is the way that most software that calculates dates already works! If you're a spreadsheet person, try this: open up your spreadsheet software—Excel, LibreOffice or, if you don't have any of these, Google Sheets. Select a cell and type in today's date (or press Ctrl+;). Select another cell and type in your birthdate. Select now a third cell and create a cell to subtract your birthdate from today's date. Once you press enter, the result that you should see is the number of days old you are. Divide that by 365.2425, and you should get your age in years.

The reason this works is because each cell in a spreadsheet has a value and a format. The format that you see is the date represented in the cycles that we humans are used to (i.e., years, months, days). However, the value that's in the cell is a number. If you want to see this number, select a cell and then change the number format for the cell to ‘General’ or ‘Automatic’. (This process is different in different spreadsheet programs.) It goes the other way around. Type ‘37045’ into a cell. Now, change the number format of the cell to a date. You'll end up with 2001 June 3.

If we take that table of dates from above and put it in a spreadsheet, we'd end up with this data:

 Lance 20368 20559 29728 30227 30855 31069 31475 37382 39348 40466 41169 41363 41731 42152 42155

While that's what the spreadsheet will actually store in the background, we can give the spreadsheet instructions to format the data however we want. It will convert the dates from these linear formats into the cyclical representations that we humans deal with. How those conversions are done is a topic for another time, but these dates on a linear scale are an improvement. Remember how I said that mathematical calculations are exactly deplorable with cyclical representations? Well, now, mathematical calculations are elegant and straightforward. Need to know what date it will be a hundred days from now? Tell the spreadsheet to add the days and let it do the math for you!

If you would like to comment on something that you read, by all means, leave a note here. Please note that all comments are approved before being displayed to prevent spam comments.

 Name: E-mail: Subject: Text:

## Time is the fire in which we burn.

So, the last time that I wrote a blog post here—nearly a year and a half ago—I was talking about a new software project that I had been working on for, at the time, about six months. I had said that the project was “pretty much already done”.

That part about it being pretty much already done… was not exactly the truth. There was also another lie: the one about my starting the project six months before the last blog post. In truth, I started this project back in college. Untruths aside, I think that my software project—despite being still unfinished—is done enough that I can finally let you in on the secret.

So, context: I grew up in what could be described as an evangelical environment. Each religion seems to have its holidays—and Christianity is no exception to that rule. However, my particular brand of vodka of Christianity certainly hadn't gotten that memo. Growing up, I seem to remember three Christian holidays: Christmas, Easter and Palm Sunday—end of list. I make the joke that, despite being Pentecostals, we didn't even celebrate Pentecost. Of course, my church also celebrated Independence Day, Memorial Day or any other day set aside for nationalistic glorification with the same sincerity because it conflated nationalism and spirituality (a disturbing trend that's a topic for another time).

Anyway, despite having just three holidays, there was still this awareness that there were other holy days. Of course, you couldn't escape Saint Valentine and Saint Patrick's days. Some people reminded us that Halloween had it's origins in Christian tradition before being appropriated by… satanists or something ('cause, you know, satanists and their candy…). Around Christmas time, you neither can't escape the barrage of Christmas carols—among them, “The Twelve Days of Christmas”. This raises the question: Twelve days? Well, which twelve days are these twelve days: the twelve before December 25 or the twelve after? (Spoiler alert: It's the twelve days after.)

Attending a Christian university, there was a little more exposure to these other holidays. Once, a professor asked us students if we were attending chapel on this particular day because it was “Monday Thursday”. What the !@#\$ is “Monday Thursday”?, I thought to myself. Fortunately, that was the beginning of the Wikipedia age where, if you really want to know something, an answer was no further than the closest computer. (However, this was still before the smartphone age where answers now are no further than your pocket.)

Being a computer-science student, during my senior year, I chalked together a little one-page, PHP script that, for any year that you gave it, would spit out a liturgical calendar. It was pretty minimal; it showed just a few holidays, it marked the beginning and the end of the liturgical seasons and it showed each particular day on the calendar in its appropriate liturgical color, but that was about it. PHP has a built-in function that made calculating the date of Easter easy, so there wasn't a great deal of effort that went into it. After a bit of time, that calendar just stayed forgotten in the deep recesses of my website.

Let's jump ahead about eight years. I'm now in a new religious tradition. Specifically, it's a tradition that is overflowing with various “holy days” (which is the etymology of the word holiday). After a few months in my new church, I pulled out the old calendar that I made in college and reworked it.

By reworked, I mean I burned down the old PHP calendar script that I made and started fresh. I made a second “object-oriented” attempt that was more trouble than it was worth, so I burned that one down too and started over a second time.

Third time's a charm… as the saying says. It is still a work in progress, and I've spent countless (as in, I've literally lost count) hours working on this, and I anticipate that I'll be spending plenty more. I still don't feel that it's “ready”, but, if all goes according to plan… it'll never be ready. However, I just discovered that my calendar has started to show up in some Google searches, so I've decided that it's time to release it. Just yesterday, I registered liturgical-calendar.com and moved the calendar from this website over to its new domain.

My new website displays the liturgical calendar of the Anglican Church of North America (which itself is a work in progress). In addition (while I haven't yet built any sort of way to switch between the two—it is a work in progress after all), I also included the liturgical calendar according to the Episcopal Church's 1979 Book of Common Prayer.

I could really talk a while about the nice features that I put into it, but I will just mention a few:

One, in true linguistics-nerd fashion, the capability to have the calendar available in multiple languages was built in from the start, and, as such, I included translations into Spanish and French.

Two, the calendar provides links to other websites for scripture readings. However, Anglicans don't necessarily use ordinary Bible translations when reading the Psalms. Typically, a separate psalter is provided within each of the various versions of the Book of Common Prayer. Since I couldn't find a decent website with the psalter, I created my own website of the psalter. The psalter website still needs a lot of work, but that in itself was a monumental task for something that's kind of an afterthought.

Three, while the calendar was programmed in PHP, I also rewrote all of the functionality in JavaScript as well so that moving from page to page within the site becomes lightning quick! For this project, I actually programmed it TypeScript, a computer language from Microsoft that adds static typing to JavaScript and then compiles to JavaScript. The lack of static typing is a frustration for me in both PHP and JavaScript (among other computer languages), and I'm thrilled that tools now exist for static typing.

Lastly, while Christians in “the West” all use the Gregorian calendar for their feasts and fasts, I included functionality for the use of calendars used by Christians in “the East” such as the Julian, Coptic, Ethiopic and Revised Julian calendars. For good measure, I also threw in the Hebrew calendar too. While I'm not actually using this functionality right now, it's… there. In the future, I may expand the website to include calendars from other traditions besides just the Anglican one. However, to include this functionality, I am indebted to Edward M. Reingold and Nachum Dershowiz for their fantastic book Calendrical Calculations which contained and explained all of the mathematics that I needed to support all of these calendars (except the Revised Julian calendar which I had to create myself). When it became clear that I needed something to help me with the calculations, I read online that Reingold and Dershowiz' book was the one to use. After reading it, I recommend it for anyone seeking an understanding of calendrical calculations.

It's been a good deal of work, and it's been a great deal of fun. Going forward, I hope to continue to work on this project, and I hope that it can be of use those who have great liturgical-calendar needs! Also, I hope that this gives me more things about which to write blog posts. I encounter a bit of frustration when I see examples of software development that don't properly compute dates and times correctly. I've gotten into more than a couple of arguments at work about this. Hopefully, I can write a few blog posts on this topic in the near future to inspire good coding practices. Right now, it's a miracle that I wrote this one.

If you would like to comment on something that you read, by all means, leave a note here. Please note that all comments are approved before being displayed to prevent spam comments.

 Name: E-mail: Subject: Text:

## Recreating PC Globe, Part 0.1: The End

So, the last time that I wrote anything here… was 2015. I think that it's about time to admit that my project of recreating PC Globe isn't happening.

I did make some progress. I managed to make a map-projection demonstrator, and I managed to create (by hand!) SVG flags for many countries (despite the fact that Wikipedia has a list of every single flag that I would have ever needed).

I've decided at this point that I'm never going to end up finishing it.

However, over the past… six months, I did start a new software project that's pretty much already done, so all that remains is to write blog posts about it.

If you would like to comment on something that you read, by all means, leave a note here. Please note that all comments are approved before being displayed to prevent spam comments.

 Name: E-mail: Subject: Text:

## Recreating PC Globe, Part 0: Introduction

So, I've had computer trouble lately. My laptop died, and I had nothing backed up. Fortunately, I purchased a replacement, and I was able to recover my data in spite of the fact that I had nothing backed up. That is a mistake that I won't let happen again.

Anyway, we're well past the holidays at this point. However, due to the aforementioned computer problems and just general laziness on my part, I'm finally getting around to throwing up another blog post that I meant to throw up during the holidays. This Christmas, I managed to get three of my nieces a globe as a present. Perhaps the gift says more about me than it does my nieces: the oldest of the nieces is four years old. When I was about four years old (back in 1990), my father installed a neat computer program on our 25 MHz, 386 personal computer: PC Globe. That, combined with other geographic artifacts such as Where In The World Is Carmen Sandiego? and a real globe that my grandmother bought for my brother, began a hopeless descent into the world of geography nerdism that still haunts me today.

Anyway, PC Globe: it was a DOS program that was a cross between an atlas and a statistics book containing data on various countries. It had a slick (for the time) point-and-shoot interface; you pointed the mouse cursor over a country on a map and clicked the mouse button. Up popped information about the country that you clicked on: population estimates, age distribution, GNP, languages spoken, ethnic groups, religions, imports, exports… you get the idea. One very neat feature was that you could even get it to display the country's flag while it simultaneously played that country's national anthem on the computer's shitty internal speaker.

I still have a copy of the program. However, it has to be run it through DOSBox because of technical issues. I run it purely for nostalgia purposes; it's entirely useless as a usable tool in this day of age mostly because it's out of date. Remember how I said 1990? If you remember correctly, that was during a period of transition. The Berlin Wall fell in 1989, and the Soviet Union collapsed in 1991. I remember, after being told that the USSR had broken up into smaller countries, calling my father at his workplace to ask him if he could “draw lines across Russia” in PC Globe once he came home from work.

He never did. As disappointed as I was then (i.e., I wasn't), it's entirely understandable to me know how my father didn't want to spend hours hacking someone else's proprietary software… even though he was a computer programmer. Even if he wanted to, writing software back then was incredibly different; mainly, there was no World Wide Web to rely on: that means no Google, no Stack Overflow and no way to download all of the free programming tools… and then there's data. PC Globe wasn't just an electronic atlas: it was a database of a ton of information about each country. We don't appreciate enough the fact that, before Wikipedia, we had paper encyclopaedias. If you wanted up-to-date information, you had to purchase a new set.

Today, none of those limitations exist, so I can finally set out to break the Soviet Union apart. However, rather than tweak the original program, I'm going to recreate my own atlas and database. It's probably going to be an overwhelming task to begin with. Then, once I'm finished, I have the impossible task of… keeping the information up to date.

Yeah.

My finished result probably isn't going to be a perfect clone of PC Globe. I wouldn't want to recreate it exactly anyway even if I could. Besides, this project isn't about the product; it's more just for fun… and nostalgia.

If you would like to comment on something that you read, by all means, leave a note here. Please note that all comments are approved before being displayed to prevent spam comments.

 Name: E-mail: Subject: Text:

## Alcohol by Volume vs. Alcohol by Weight

Let's talk about math. If math scares you, don't worry: we're really going to talk about beer.

Beer (or any alcoholic drink for that matter) is mostly just water with some ethyl alcohol thrown in for good measure and trace amounts of other stuff that provides the flavor. Typically, about 5% of a beer is alcohol, so a 12 floz serving of beer will have 0.6 floz of alcohol. Now, I said that a beer is typically 5% alcohol: beer does come in many different strengths. For example, last night, at the Wynkoop Brewing Company, I had a beer that was 8.2% alcohol, and, because the content was so high, the bar gave me a “short pour” which means that they gave me a brandy snifter's worth of beer.

One common strength of beer that is seen especially in the retail area is 3.2% beer. In Colorado, where I live, beer can only be sold in a grocery store if its strength is less than 3.2%. If you're fine with drinking 3.2% beer, you can pick up your watered-down, mass-marketed, American pale lager at the same time you buy your milk and eggs. If you prefer wine, whisky or beer that's stronger than 3.2%, you need to make a special trip to the liquor store.

So, if we do the simple math on this and divide 3.2 by 5, 3.2% beer has only 64% percent of the amount of alcohol that a normal 5% beer has. That math would be fine except that it's completely wrong.

For some legal or historical oddity that I think has to do with taxation laws (but I am not sure), when a beer advertises itself as 3.2%, what it means is 3.2% by weight as in 3.2% of the total weight of the liquid is alcohol. Just about every other time you look at an alcoholic beverage label, the alcohol content is listed by volume… and they are most definitely not the same. Well, they are the same, but only in exactly two instances: 0% alcohol by weight is 0% by volume, and 100% by weight is also 100% by volume. However, between those two extremes, the relationship is not linear.

Most calculators that I come across on the Internet, however, do assume that the relationship is linear with the common assumption that the alcohol by weight (ABW) is 80% of the alcohol by volume (ABV). This may be close enough for the range of alcohol that covers most beers, but “close enough” only counts in horseshoes and handgrenades. We can do better.

So, let's think: how is alcohol by volume (or ABV) defined? Well, it's a ratio of the volume of alcohol divided by the total volume. Now, the total volume of an alcoholic beverage is alcohol and water… and some other stuff that provides the taste, but for our purposes, let's just ignore that other stuff—alcohol, water and nothing else. When we put it together, we get something like this:

$$ABV = \frac{VolumeOfAlcohol}{VolumeOfAlcohol + VolumeOfWater}$$

Okay, but we're dealing in weights—not volumes. Since a volume of something is equal to the weight of that something divided by its density, we can replace the volumes with weights, so let's consult Wikipedia (the most peer reviewed publication on the planet). If we look up the appropriate articles, we'd find that ethyl alcohol (the type used in alcoholic beverages) has a density of 0.78945 kilograms per liter at 20°C (68°F). At that same temperature, water has a density of 0.9982336 kilograms per liter. For this exercise, let's round it at 0.99823 kilograms per liter. If we replace the volumes in our equation, we end up with:

$$ABV = \frac{\frac{WeightOfAlcohol}{0.78945 \frac{\mathrm{kg}}{\mathrm{l}}}}{\frac{WeightOfAlcohol}{0.78945 \frac{\mathrm{kg}}{\mathrm{l}}} + \frac{WeightOfWater}{0.99823 \frac{\mathrm{kg}}{\mathrm{l}}}}$$

…and if we simplify that, do the dimensional analysis and eliminate the decimals, we get:

$$ABV = \frac{99823 \cdot WeightOfAlcohol}{99823 \cdot WeightOfAlcohol + 78945 \cdot WeightOfWater}$$

Our units cancel out in the dimensional analysis, which, since the ABV is a ratio, makes sense. Now, remember when I said that we're dealing with weights? I lied. What we actually know is the alcohol by weight (ABW), and we know the ABW is the ratio of the weight of the alcohol to the total weight. This is very similar to the equation that we started with for the volumes:

$$ABW = \frac{WeightOfAlcohol}{WeightOfAlcohol + WeightOfWater}$$

Well, we could try to solve this all as a system of equations. Let's solve our ABW equation for either the weight of the alcohol or the weight of the water. (It won't matter which one in the end, but let's pick weight of water.) When we go through the steps to solve for the weight of water, we get:

$$WeightOfWater = \frac{WeightOfAlcohol \cdot (1 - ABW)}{ABW}$$

Let's plug that into tho ABV equation and simplify. If you've been following along on your TI-89 from high school, you should get:

$$ABV = \frac{99823 \cdot ABW}{20878 \cdot ABW + 78945}$$

…and there's our formula. What's interesting is that when we plug in the weight of water from the ABW equation, the weight of the alcohol gets canceled out. If we would have plugged in the weight of alcohol instead, we get the same results.

If you need to convert the other way around (i.e., obtain the ABW from an ABV), you just need to solve the above formula for ABW:

$$ABW = \frac{-78945 \cdot ABV}{20878 \cdot ABV - 99823}$$

So, when we put 3.2% into the equation for the ABW, we come within a rounding error of 4.0%. Remember how we did the math and we said that 3.2% beer is 64% as strong as regular beer? Well, it turns out that, since 3.2% beer should really be marketed as 4.0% beer, it's really 80% as strong as regular beer. Keep that in mind before you consider chugging down another 3.2% bottle after you've already had a few: it may be more potent that you think.

Tags: Beer, Mathematics