Longevity Graphs

There are many uncertainties associated with one's retirement years. This project is about retirement income – how much income will be available in each year and for how many years will income be needed. There will be much to say about the generation of income but a key aspect of any strategy for producing retirement income is the question of how long it will be needed.

To put it crassly – how long will the primary recipients of income live?


Very few want to address this question. But it is a key component of the process required to make sensible financial decisions in retirement. The programs that I will develop will rely heavily on longevity probability estimates. Hence it seems suitable to start the Retirement Income Scenarios (RIS) software with such estimates.


Consider Bob and Sue Smith, whom we will call “The Client”. Bob is a 66 year old male and Sue a 63year old female. How long will they live? The answer is almost certainly that no one really knows. To approach this question in any rational manner one must deal with probabilities. Let's say that the probability that Bob will die next year is 1.3%. This means that out of cohort of 1,000 men of Bob's age, 13 are likely to die in the next twelve months. To put it more positively, 987 of them are likely to survive to reach 67.


Mortality tables contain estimates of the probabilities of death at various ages for people in a particular segment of society. There are usually different tables for male and female members of that segment. Based on the numbers in the tables, estimates can be made of the probabilities that an individual or a pair of individuals will live to various ages. These are the probabilities shown in the RIS longevity graphs.


For the RIS software I used tables provided by the United States Society of Actuaries based on statistics about the longevity of participants in a number of retirement plans in the U.S. The basic RP-2000 tables give estimated mortality probabilities for the year 2000 for (1) males and (2) females of various ages. The original data concerned mortality rates for employees up to age 70 and “healthy annuitants” (those receiving retirement benefits) from ages 50 through 120. Then these were combined to provide “combined healthy” mortality rates for all ages through 120 – the numbers that I used. For details, see the RP-2000 mortality tables.


The Society of Actuaries has also produced two mortality improvement tables (BB) – one for males, the other for females. These provide estimates of the annual improvement in mortality for each age (although the annual improvements are zero for the lowest and highest ages). By applying these each year, it is possible to produce, in effect, a table for 2001, 2002, …, 2013, 2014 ,... and so on. The client settings in the RIS program include the current year to allow for updating to the present. Then the factors are used to compute estimates of future mortality. Thus Bob's mortality next year when he is 67 will be given by this year's mortality for a 67-year old plus the one year's mortality improvement using the factor for that age. The mortality for Bob the next year when he is 68, will be given by this year's mortality for a 68 year old male plus two times the annual mortality improvement factor for that age. And so on. For more on scale BB, see Mortality Improvement Scale BB.


Of course, no one really knows the percentage of males or females of a given age that will die in each future year. There is thus uncertainty about the probabilities computed in this manner. I like to call this “table risk”. We don't really know what the future statistics will be. What if there is a cure for a major type of cancer? What if there is a nuclear holocaust? What if an antibiotic-resistant virus spreads around the world? The retirement income scenarios in my software will ignore this additional source of uncertainty. But insurance companies that sell annuities quite rightly worry about it a great deal, charging higher prices than would be dictated by standard annuity tables in order to provide a cushion if mortality rates increase (for life insurance) or decrease (for annuities). To some extent, this danger can be mitigated by issuing both types of policies, but life insurance is (appropriately) purchased mostly by younger people and annuities (appropriately) by older folks, so any offsets will be, at best, imperfect. I'll have more to say about the pricing of annuities and possible societal approaches for dealing with such table risk in later blogs.


In practice there are many different mortality tables. Insurance companies use tables with higher mortalities when computing prices for life insurance policies, to reflect the likelihood that the pool of applicants will be less healthy than the average person (adverse selection) and that people with such policies might take more risk (moral hazard). Conversely, insurance companies use tables with lower mortalities for annuity policies, on the assumption that the pool of purchasers will be more healthy than the average person and likely to take better care of themselves.


The U.S. Internal Revenue services requires corporate pension plans under its jurisdiction to use the RP-2000 tables with mortality improvement. A number of academic studies have utilized the tables as well. Hence my choice.


Now, to the Longevity Graph feature of the RIS software.


To access the current version of the software, go to scratch.mit.edu and type wfsharpe in the search box. Then click on the latest RIS version shown. Click the green flag. You will see two buttons. Click the “Client Settings” button to see the current settings and to put in your own information. To leave a setting as is, simply press the Return key. When you are finished you will return to the main menu.


At any time (except when you are entering inputs), you may press the keyboard up arrow to turn context-sensitive help on or off. You may also return to the main menu by pressing the keyboard left arrow.


To make the software run faster at any time hold down the Shift key and click the green flag at the top of the window to place Scratch in turbo mode. To show the information in full-screen mode, click the icon at the top left of the window. To return to the smaller version, click it again.


If you sign up for a free Scratch account, you may look at and, if desired, modify the software and save the revised version as a project in your own account at the Scratch site or on your own computer. If you have modified the client settings, the latest information will be saved with the software and will be available when you re-load it.


So much for logistics – back to substance.


If you feel that you or your partner are more or less healthy than the average healthy person of your age, you may want to put in a different age than your actual physical age. There are web sites that will give you an estimate for this purpose. I have looked at several and found them wanting. Some are blatant attempts to get your health information in order to sell you something (a magic elixir, anyone?). Others seem quite crude. I tried one that provides your “death date”. It took my health information, then told me that my death date had passed and parted by telling me to have a nice day (I'm not making this up). My friends confirmed that I am not yet dead (Monty Python fans will recognize the phrase). Perhaps the best approach is to ask your family doctor for his or her estimate of your effective age, health-wise.


Once you have changed the client settings, click the “Longevity Graph” button and you will see your personal Longevity Graph. Here is the one for the Smiths:

Each bar shows the probability that (1) both you and your partner will be alive in a future year, (2) only you will be alive in that year, or (3) only your partner will be alive.


If you do not have a partner, change the client settings to make your fictional partner 120 years old. This rather crude approach will insure that he or she is not around in any future year.


Of course in any specific projected future scenario you will live some specific number of years, as will your partner, This will be evident with alternative possible scenarios are shown in future versions of the RIS system. But the probabilities shown in the longevity graph provide some context as you think about alternative retirement income strategies.


You may find all this terribly depressing. It is not pleasant to even think about dying and to consider the chances that you and/or your partner might not be around in some near or distant future year. On the other hand it may be depressing to think about the possibility that you will need income for decades in the future. I share your pain. But longevity is truly a fact of life, and it is one of three major uncertainties that must be faced when making plans for retirement income (the other two are investment returns and health issues). Forewarned is forearmed.

Why Scratch?

As indicated in the previous blog, I am developing a suite of software dealing with retirement income scenarios using the Scratch programming language. Those who know something about Scratch may consider this a strange choice. Here I'll try to show why I consider it well suited for this project.

I have been writing computer programs for over fifty years. My PhD dissertation included (in addition to an early version of the Capital Asset Pricing Model) the description of an algorithm for solving a special class of portfolio optimization problems and a program for implementing it. Since then I have written programs in a variety of languages. I published the first commercial book on the BASIC language and wrote an interpretive compiler to implement it when I was at the University of Washington. For my own research I now use Matlab, a scientific programming language. For years I used the standard Matlab constructs but now rely on the more recently added object-oriented capabilities. I love to program – there is much gratification when a program does what you intended it to do -- more than enough to offset the frustration when it doesn't.

I also feel very strongly that everyone should be exposed to programming as part of the curriculum in Junior High School and/or High School. The benefits are many. Students can learn to think logically, divide complex tasks into a series of sub-tasks, test ideas rigorously, and explore aspects of mathematics, statistics and many other fields by doing experiments. They can also gain a deeper understanding of the ways in which computers, tablets, phones, televisions, movies and many things we encounter in our daily lives do what they do. Most people now spend hours every day interacting with technology but in an important sense they are interacting with programs. One hears “the computer did such and so” but it would be more accurate to say that a program made the computer do it.

Most important, as the Scratch team emphasizes, one can experiment and be creative when writing programs – far more so than when using programs written by others.

Unfortunately, programming is included in the required public curriculum in only a minority of public schools in most countries. There are groups trying to fill this need – see, for example,Computer Clubhouse, Coder Dojo, and Code.org. But far more is needed.

Since I had never taught pre-college students, I thought it would be a good idea to understand more about the benefits and challenges associated with including programming in the curriculum. I began by researching languages that would be suitable for doing so. I very shortly narrowed my list to one – the Scratch Programming Language developed at the Massachusetts Institute of Technology (MIT) ( scratch.mit.edu)– for reasons that I'll give shortly. I spent some time learning the rudiments of the language and then volunteered to teach it to a small group of middle school students in a summer program sponsored by the Community Partnership for Youth in Seaside California, near my home in Carmel. I had a great time, as did the students. We wrote programs to create designs using geometric figures, to administer arithmetic tests, to run a horse race and to allow people to play pong. The students learned key aspects of logical thinking, how to break tasks into key components, and some applied mathematics. They also gained a better understanding of how much of the world of technology works. I learned as much from them as they did from me. Most importantly, it was great fun for us all.

More than ever, I am convinced that the school curriculum needs to include programming. And that the best language, at least for the first course, is Scratch.

Scratch was developed and is supported by the Lifetime Kindergarten research group at the MIT Media Lab. Work began in 2003 and the first version was launched publicly in 2007. At present there are over one million members of the Scratch Community and over three million projects have been posted on the Scratch web site.

Here is a description of the choice of the name from a 2009 article by the members of the team ( Scratch: Programming for All).

“The name 'Scratch' itself highlights the idea of tinkering, as it comes from the scratching technique used by hip-hop disc jockeys, who tinker with music by spinning vinyl records back and forth with their hands, mixing music clips together in creative ways. In Scratch Programming, the activity is similar, mixing graphics, animations, photos, music, and sound.”

The most recent version, Scratch 2.0, became public in May, 2013. It allows users to write, edit and run programs using only a browser. Programs may also be downloaded to the user's computer. A downloadable version of the language editor and processor is also available (in a beta version as I write this).

Anyone may join the Scratch community, create programs, and, if desired, make them available on the Scratch website. Any program made public by its author may be used by anyone. It is also possible to “look inside” to see a public program's code. Anyone may adapt such a program for other uses, subject only to the terms of a Creative Commons attribution and sharing license. As indicated earlier, users are encouraged to “remix” existing programs in order to create new capabilities (with attribution, of course) .

There are no charges. The Lifetime Kindergarten group has received support from the likes of the National Science Foundation, the Intel and Microsoft Foundations, the MacArthur Foundation, Google and many others. Your support is also welcome but not required.

It should not be surprising that an undertaking of this importance and quality comes from MIT. A legendary pioneer in the use of computers by people of all ages was Seymour Paper, who developed the Logo programming language. Indeed, Mitchel Resnick, the head of the Lifetime Kindergarten research group, recently published a description of the genesis of Scratch under the title Reviving Papert's Dream.

This is not the place for a detailed description of Scratch. Resnik's recent paper is an excellent introduction, as is the formerly cited 2009 paper by the entire Scratch team. Here I'll give just a flavor of why it is different from most conventional programming languages.

First, there are no error messages because it is very difficult, if not impossible to make a syntactic error. The grammar is based on a set of graphical programming blocks and items that are “snapped together” to create a program. And the items have shapes and colors that indicate their nature. If a something doesn't fit in a location, it can't be used in that manner. This avoids myriad errors, at the relatively small cost of requiring more grabbing, moving and assembling than required in most programming languages.

Scratch has many attributes of a modern object-oriented programming language. Objects (called sprites) can have local variables and methods. Sprites communicate by broadcasting and receiving messages, which allows for more modular programming and event-driven execution. As indicated earlier, there are features that facilitate animation, graphic user input, graphic output, sound, inclusion of photos, external material and much more. If desired, programs can even be written to process input and output from some external devices.

All these features make Scratch ideal for its intended purpose. The 2009 paper states: “The core audience on the site is between the ages of eight and 16 (peaking at 12), though a sizeable group of adults participates as well.” The students that I taught were between 11 and 13 and I can attest to the suitability of Scratch for that demographic. But next year I will be five times as old as the upper limit of the range for the core audience. Is Scratch right for me and for my work on retirement income? I think so.

As I have learned more about Scratch and used it for complex projects, I have realized that the underlying structure is truly brilliant. The structure has been carefully crafted to allow great generality but with consistent and highly logical underpinnings. To be sure, there are limitations, but one can get around most of them or adapt as needed. At present I have not stressed the system by attempting very large simulations with sizable intermediate data, but early experiments indicate that Scratch can accomplish rather complex tasks quite efficiently.

So, here is my plan. I will start with an overall structure that allows me to add features as items on a menu. The first release will have only one such feature (a “longevity graph”). Subsequent releases will add other features, all related in some manner to the forecasting and analysis of retirement income scenarios. I invite you to try the programs. Together we will see how far this undertaking can go.

Retirement Income Scenarios

This blog will be devoted to discussions of issues surrounding the provision of income for a person or couple during their retirement years. Much of the analysis will be conducted by forecasting a number of possible future scenarios, then analyzing the properties of chosen strategies for producing retirement income across the scenarios. I call this approach “retirement income scenario analysis”. It uses the method of Monte Carlo simulation with an underlying set of assumptions about the behavior of capital market and macro-economic variables as well as an assumed basis for valuations of possible future cash flows.

Since it is important to generate sufficient scenarios to provide a representative set of possible future outcomes, computer programs play a central role in the analyses. I have developed a series of routines for large-scale projections using the Matlab programming language, taking particular advantage of its object-oriented capabilities. I have been using Matlab for decades and find it an excellent language for scientific analysis. However, there is no simple way to make Matlab programs available for use by those who have not purchased the software or have access to it through colleges and universities. Hence I do not plan to try to make these programs available for use by others. Instead I will use the Matlab programs to illustrate and illuminate some of the fundamental relationships involved in retirement income planning.

Fortunately, there is a programming language that can freely be used by anyone, and a supporting system that allows programs to be made available for use, study and modification by others. Moreover, only a standard web browser is required to use the system or to run programs written in the language. Its name? Scratch. I am in the process of preparing a series of programs written in Scratch that will be available for anyone to use, study or modify.

I'll discuss Scratch and the reason why I chose it in some detail in the next blog. Subsequent blogs will describe the components and capabilities of the Scratch programs as I complete them and make them available. I call the overall system RIS, which stands for Retirement Income Scenarios. As befits the subject of a series of blogs, this is an ongoing undertaking, with capabilities that will grow over time.

Of course there will be more in the blogs than discussions of programs. Much of the material will deal more generally with key aspects of the economics of retirement income..

There is much to cover. Please join me in trying to understand and explore the many relevant aspects of this crucially important topic.