MAPL
A Mathematical-Actuarial Programming Language
Robin Perz
rperz86@gmail.comJanuary 23, 2016, 67 pages
Supervisor: Tijs van der Storm Host organisation: CWI,http://www.cwi.nl
Universiteit van Amsterdam
Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering
Contents
Abstract 4 1 Introduction 6 2 Project Setup 8 2.1 Initial Study . . . 8 2.2 Problem Statement . . . 8 2.2.1 Research Questions. . . 9 2.2.2 Solution Outline . . . 9 2.2.3 Research Method . . . 10 2.3 Contributions . . . 11 2.4 Related Work . . . 113 Background and Context 13 3.1 Domain Specific Languages . . . 13
3.1.1 What is a DSL? . . . 13
3.1.2 Why DSLs? . . . 13
3.1.3 DSL Composition . . . 14
3.1.4 Language Reuse . . . 16
3.2 Writing a DSL in Rascal . . . 18
3.2.1 Creating a compiler for a DSL in Rascal . . . 18
3.3 Actuarial domain . . . 19
3.3.1 Payment structures. . . 20
3.3.2 Pension types . . . 20
3.3.3 Actuarial assumptions . . . 20
3.3.4 Actuarial calculations . . . 22
4 MPPL: a DSL for discrete mathematics 24 4.1 Syntax . . . 24
4.1.1 Formula . . . 24
4.1.2 Sum operator . . . 25
4.1.3 Product operator . . . 25
4.1.4 Basic math operators . . . 25
4.1.5 Vector indexing. . . 25
4.1.6 Powers. . . 25
4.2 Type checker . . . 26
4.2.1 Duplicate declarations . . . 26
4.2.2 Ambiguous use of variable . . . 26
4.2.4 Unused variables . . . 27
4.3 Evaluator . . . 27
4.4 Preview . . . 28
4.4.1 Code Generator. . . 28
5 MAPL : A DSL for pension calculations 30 5.1 Design . . . 30 5.1.1 State model . . . 30 5.1.2 Risk model . . . 30 5.1.3 Product . . . 31 5.1.4 Calculation Basis . . . 31 5.1.5 Declarations. . . 32 5.2 Example program. . . 33 5.2.1 Execution . . . 33 5.3 Type System . . . 34 5.3.1 Undeclared variables . . . 34 5.3.2 Type compatibility . . . 34
5.3.3 Function call consistency . . . 35
5.3.4 Statemodel consistency . . . 36 5.3.5 Extension compatibility . . . 36 6 Implementation 38 6.1 MPPL . . . 38 6.1.1 Type Checker. . . 39 6.1.2 Preview . . . 39 6.2 ActSL . . . 41 6.2.1 Type Checker. . . 42
6.2.2 Statemodel consistency Checker. . . 43
6.2.3 Code Generator. . . 44
6.3 MAPL . . . 45
6.3.1 Type Checker. . . 45
6.3.2 Code Generator. . . 47
7 Evaluating effectiveness 50 7.1 Experiment #1: Using the mathematical DSL to create new calculations. . . 50
7.1.1 Experimental setup. . . 50
7.1.2 User study results . . . 50
7.1.3 Analysis . . . 51
7.2 Experiment #2: Using the mathematical preview to audit calculations . . . 51
7.2.1 Experimental setup. . . 51
7.2.2 User study results . . . 52
7.2.3 Analysis . . . 52
8 Discussion 53 8.1 Threats to validity . . . 53
8.2 Future work . . . 53
9.1 Question #1: How can we compose two languages and keep the mathematical DSL independent? . . . 54
9.2 Question #2: What is the effect of the mathematical DSL on the implementation time of a calculation by an actuary? . . . 54
9.3 Question #3: What is the effect of the mathematical DSL on the auditing times of calculations by the actuary? . . . 54
9.4 Main Question: How can we improve actuarial software development? . . . 55
Appendices 56
A MMPL grammar 57
B ActSL grammar 60
Abstract
We present MAPL, a domain-specific language for actuarial products. The MAPL implementation adds mathematical notation to the AML language. MAPL generates Java source code from a pension specification and its accompanying calculations. MAPL is a composition of two languages.
The first language is an implementation of AML implementation, called ActSL. The ActSL im-plementation has been derived from the description in [10]. This is a life insurance and pension specification language, with an external calculation kernel. We have added a mathematical language to simplify the creation of new calculations as this is a common task for the actuary.
The second language is a mathematical DSL based on the AMS-LATEXpackage. We have created
a subset of this package, to suit the needs for the creation of discrete pension calculations. This language also includes a mathematical preview of the written AMS-LATEXcode using MathJax. The
preview also makes use of existing work in the Rascal-MPL.
Finally, we have executed a user study to show the use of our DSL. In the first experiment, we show that the DSL decreases the implementation time of new calculations for junior actuaries. In the second experiment, we show that auditing of calculations is not only faster, but also increases the correctness of this auditing.
Preface
Before you lies my thesis, part of the Master Software Engineering at the University of Amsterdam. I would like to use this opportunity to thank some of the people who have made this possible. First of all, I would like to thank my supervisor Tijs van der Storm, for his time and guidance during the months I’ve worked on this thesis. To see the difference between the first draft of this thesis and the end result is a good show of the improvement thanks to the comments of Tijs. Next to Tijs, I would like to thank the other guys of the SWAT team at CWI, for always answering any questions about the Rascal language in quick fashion. This thesis wouldn’t have been possible without the cooperation of the junior actuaries at Towers Watson, so I thank them and my office leader Floris van Rijn for agreeing to their cooperation. Also, I want to thank the rest of my colleagues, especially Wouter Tuyp and Rick Laan, for their constant nagging about completing my thesis. They probably took about a month off of the completion time by annoying me. Finally, I want to thank my parents for supporting me in the decission to start another track which led me to this Masters degree. I hope you will find this thesis as interesting as it was to write it.
Chapter 1
Introduction
The actuarial product space is a complex world of mathematical formulas. Bringing statistics and mathematics together, the actuary calculates values for pensions and life insurance to be able to advise pension funds and employers on their pension plans. They have to take into account all sorts of demographics, for instance mortality, disability and withdrawal probabilities, to be able to calculate the expected cashflows of the different types of pensions and insurances. Each type of pension can be calculated using different assumptions. A spouse pension for instance, which is an annuity that is paid to the spouse at death of the insured, can be estimated taking marriage frequencies into account, taking possible exchange for old-age pension into account, using mortality improvements and many other assumptions.
As a solution to this problem, at the University of Copenhagen a DSL for life insurance products and pensions[10] was developed. This thesis replicates the language created in this study and adds value to the language. The language, known as Actulus Modeling Language (AML), splits the actuarial world in four important pieces.
First, all pensions and life insurance products depend on the state of the insured. For this, AML defines a state model, which defines the states that are used to define the product. It also defines transitions between these states, as this can also be a part of the product definition.
Second, it defines a risk model. The risk model is used to define the transition rates of the insured persion. This is necessary to be able to calculate the chance that a certain participant is in a certain state.
Third, it defines the product. The product is defined by the payment structure. It specifies how many payments need to be made and in which circumstances. This is the basis of all actuarial calculations on pension and life insurance products.
Finally, it defines the basis. AML uses the basis to collect all information needed to calculate actuarial formulas. This includes for instance the interest or the maximum age a person can become. The AML implementation[10] uses an external calculation kernel to perform these calculations. This calculation kernel calculates the provision using a Runge-Kutta 4th order solver. As we do not use cyclic mutations in our day to day work we have not implemented the solver. Instead, we have created a separate DSL for actuarial calculations. We believe that this is of more use to an actuary, as the core of (junior) actuarial work lies in the calculation of different values. These calculations tend to be specific to what the project needs and is therefore hard to implement as a ”one-for-all” solution.
As mathematics is a domain that is used in many other domains, we have kept the mathematical DSL independent of our AML implementation, ActSL. The mathematical DSL, known as Mathemati-cal Pluggable Programming Language (MPPL), implements a small subset of AMS-LATEX. The subset
that has been included is a part of discrete mathematics and is described in section4.1. The subset is based on the constructs that are needed to perform normal pension calculations, like generating an expected cashflow or a provision.
As an additional feature to the mathematical DSL, we have created a side-by-side mathematical preview in Eclipse. This aims to help the actuary to rapidly identify mistakes in the formulas. The mathematical preview is implemented using the MathJax JavaScript library[9]. The implementation also uses previous work by the Software Analysis and Transformation team at CWI. As we have used the Rascal language workbench as the language to construct our DSL, we also have the availability of their visualization kernel. As this is HTML5-based, the MathJax library could be easily included. To keep MPPL independent of ActSL, we have used an adapter language that acts as a broker between the two languages. The adapter language is named MAPL (Mathematical & Actuarial Programming Language). If one of the two languages needs information about the other, it asks the adapter language. By using the Rascal feature to pass pointers to functions as function parameters, we also keep the ActSL and MPPL independent of MAPL. This means that we can add another language to ActSL by creating a new adapter language.
Finally, we have performed a user study using junior actuaries. These junior actuaries have per-formed to experiments. In the first experiment, the actuaries were asked to implement a given mathematical formula in MPPL. Then, they were asked to do the same in VBA. The results of the experiment led us to believe that MPPL helps the users to not only increase their productivity when implementing calculations, but also to write correct calculations.
In the second experiment, we have asked the actuaries to perform auditing on a set of given implementations of a formula. First, they were asked to do this for MPPL implementations. Next, they were asked to do this for VBA implementations. The results were again in favor of MPPL. The actuaries made less mistakes and audited more formulas.
In the next chapter, we will describe our project setup. This includes the research questions and the methods we have used to answer these. Then in chapter three, we will describe the necessary background to be able to understand the resulting DSL and the process that was followed to create it. In the first part of the chapter, we describe what a DSL actually is. In the second part of the chapter, we describe the use of Rascal-MPL to create a DSL. The last part of this chapter describes the actuarial domain and its link to AML. In the fourth chapter, the design of MPPL is described. This includes the syntax, type checker and preview. Chapter five describes the design of MAPL, our composed DSL. In chapter six, the implementation of MPPL, ActSL and MAPL is described. This includes the implementation of the preview and the composition of the languages. Next, we evaluate the MPPL language using two experiments. Finally, a conclusion and discussion of the work has been added.
Chapter 2
Project Setup
2.1
Initial Study
The study by the University of Copenhagen describes a language for life insurance and pensions called the Actulus Modeling Language. The programming language is divided in two parts.
The first part is the formal description of life insurance products and pensions that contains only pieces that can be different for different types of pensions and life insurance products. It is where the actuary can describe new pensions or assumptions on which to base the calculations that have to be done.
The second part is the calculation kernel. As the first part only contains the information necessary to perform the calculations, the language still needs a way to perform calculations. This calculation kernel is hidden in de background, namely in the destination language. This part is the same for every product. It contains for instance reserve calculations and solvency calculations.
The AML language contains continuous-time Markov Models to define the products, because these can be used for a wider variety of products. Because of this, they need to use Runge-Kutta 4th order solvers to be able to calculate provisions. The calculation kernel provides the functionality to do this. AML allows the actuary to define new products and immediately see the financial information that they need to decide on the value of the product. This can be of high value for insurance companies, as the actuary does not need to spend a lot of time on calculating the information himself or even programming the product into their calculation application.
Next to this, AML helps to create consistent product specifications. As every product has the same elements, AML will help them consistently describe these elements in an easy to learn way.
Another advantage is that changing the hardware or software basis of their IT system won’t have any impact on the product specifcation. As only the back-end of the language will change when the underlying language is changed, the specifcations will just be compiled into a different language.
2.2
Problem Statement
The complexity of the actuarial software world makes it hard to develop good actuarial software, as it takes a real expert to be able to model the actuarial product. For this reason, most of the tools and applications used by the actuaries are built by actuaries themselves. These applications are mostly spreadsheet applications, where macros have been created to be able to calculate provisions, cashflows and pension contributions. They use the VBA macro language to do this. These spreadsheet macros aren’t the ideal solution, but there are very few actuaries that have programming knowledge. As the macros can become very large and the actuaries don’t know software pitfalls or best practices, the
macros tend to get slow and hard to manage. Code smells like shotgun surgery, divergent change and even long method are found everywhere in the code. This hurts actuarial software, which needs to be 100% trusted to add value. This thesis aims to improve actuarial software by the implementation of a DSL. The design of the Actulus Modelling Language (AML)[10] serves as a basis for this.
AML implements the calculations in a calculation kernel, which is developed as a separate part of the DSL. This can not be changed by a user of the language. These calculations are one of the most difficult and error prone parts of the actuarial profession. In practice, most actuaries will test the output of an application, even after years of use of the application. Applications that are ’black boxes’ are unthinkable and untrusted. An actuary wants to be able to see what is happening in the calculation and check it against his own knowledge. It would therefore add value if the actuary can check the calculations without having to be able to read code. As a solution for this, we have created a mathematical DSL. The DSL implements the discrete math that is necessary for the actuarial calculations. As Eclipse does not contain a math editor, we have implemented a mathematical preview as a part of this DSL. The math code itself is written in a subset of LaTeX, but the live preview shows the written formula directly on screen. To show that this is useful for an actuary, we have completed a user study where we show that the time a junior actuary needs to create a calculation decreases. Next to this, we show that the auditing of the calculations can be done in less time when the auditor gets a mathematical formula instead of VBA code. As many solutions domains have their own mathematical logic, this DSL can be very helpful for other DSL developers as well. As a solution, we have created the mathematical DSL as a separate DSL, so that this can be reused in other languages.
2.2.1
Research Questions
In our work to create a mathematical DSL, we attempt to answer the following research question: Can we improve actuarial software development by the creation of a mathematical DSL? To do this, we answer the following subquestions:
• Question #1: How can we compose two languages and keep the languages independent? • Question #2: What is the effect of the use of a mathematical DSL on the implementation time
of a calculation by an actuary?
• Question #3: What is the effect of the use of a mathematical DSL on the auditing times of calculations by the actuary?
2.2.2
Solution Outline
There are several ways to build a DSL. It could for instance be created by building a parser and the code generator by hand or by generating it using a language workbench, like Rascal. In this thesis, we use Rascal to write every aspect of the language. Rascal is a language workbench used in combination with Eclipse that allows easy creation of the DSL, including IDE support in Eclipse. It has been created at Centrum voor Wiskunde en Informatica (CWI) in Amsterdam.
Our mathematical DSL uses a subset of LaTeX math to be able to write mathematical formulas in the Eclipse editor. We can then use existing solutions to generate a live preview of math.
To compose the two languages, we use an adapter language. This adapter language handles all language responsibilities that are a result of the combination of the two languages, like type checking the parameters that are passed from one language to the other.
2.2.3
Research Method
Question #1: How can we compose two languages and keep the languages independent? This research question is answered using literature research. We use the literature to find a method to compose the two languages and choose a method by evaluating the properties of these methods. One of these properties is the dependency between the languages. We validate the results using black box testing of the resulting language.
Question #2: What is the effect of the use of a mathematical DSL on the implementation time of a calculation by an actuary?
For this research question, we use an experimental setup to evaluate the value added by the DSL with respect to the implementation time.
Preliminary
First, we have made sure that the participants had little to none VBA experience. We believe that having more LaTeX experience won’t influence the result too much, as one of the reasons of choosing a subset of LaTeX was that they might have some experience in this from creating a Masters thesis. As participants are junior actuaries, none of them have finished the Masters yet.
To make sure that they can use both languages, we have provided them with a cheat sheet of the language constructs that are needed in the experiment.
Experiment
At the start of the experiment, the participant receives the formula for a provision factor of an old-age pension (see 3.3.4). This factor is one of the most basic factors there is. By using the most basic factor, we can generalize more easily over other factors, as more difficult factors lead to increasingly difficult programming for a novice, but formulas don’t get that much harder for a mathematical expert. We then ask the participant to implement this factor in both VBA and MPPL. Both programming assignments are timed and the results are kept.
Evaluation
We use the timing of the two assignments to compare the implementation time for the actuary. With this comparison we can answer the question.
Question #3: What is the effect of the use of a mathematical DSL on the auditing times of calculations by the actuary?
For this research question, we use an experimental setup to evaluate the value added by the DSL on the auditing side.
Experiment
For this experiment, the participant get 10 different implementations of a formula in VBA and 10 different implementations in MPPL. For MPPL, the preview is also provided. The participant is asked to find all errors in the given implementations. There is a time limit of three minutes per language. Evaluation
We use the number of finished formulas of the two assignments to compare the auditing time for the actuary and compare the number of correctly audited formulas to check if the results are at least as
good for MPPL as for VBA. With this comparison we can answer the question.
Main Question: Can we improve actuarial software development by the creation of a mathematical DSL?
Finally, answering the main research question of this thesis will be done using the results of the two previous subquestions.
2.3
Contributions
Contribution #1: Reusable Mathematical DSL
The first and foremost contribution of this thesis is a mathematical DSL that can be reused by future Rascal-based DSLs. By describing how to reuse the DSL and implementing the necessary internal hooks to implement your own composed typechecker and code generator, we have paved the way for future programmers. This language provides the future DSL with a code generator for LaTeX math. The description can also be used by other developers to create their own reusable language in Rascal. Contribution #2: Math Preview in Eclipse
The main attraction of the mathematical DSL is the mathematical preview. Using a combination existing technology, we have created a side-by-side LaTeX math preview in Eclipse, that can be reused by future Rascal-based DSLs. The only thing a programmer needs to do use this preview is calling a single function on the unparsed code. Ofcourse, it is best used in combination with the typechecker and codegenerator, but this requires a little more work.
Contribution #3: Actuarial DSL with reusable math
The end result of this thesis is the AML implementation, that allows importing files with mathematical formulas. This allows actuaries to create their own product and also create their own calculation kernel by reusing the math files. This allows for easy changes in the calculations and test them directly using the product in the specification.
Contribution #4: User studies
Finally, we have tested the use of the MPPL language on a small group of junior actuaries. We have shown that, for this group of actuaries, the MPPL language clearly improved implementation time. Next to this, we have shown the use of the MPPL language for the auditing of calculations. Although the auditing time and correctness improved, it is not as clear as for the implementation time.
2.4
Related Work
There have been multiple implementations of domain specific languages for actuaries. The first example is the Actulus Modeling Language, on which this thesis is based. We will first describe the other language with its similiarities and differences from our work and then we will continue with other work in DSLs, finance and math.
Capgemini Pension Workbench
At Capgemini, a DSL was developed that was named Capgemini Pension Workbench (CPW)[7]. Unfortunately, this DSL is not public. A presentation was given at QCon 2008[17], where the CPW
was unveiled. As our own DSL, this DSL focusses on the working actuary. While AML is developed for life insurance and pensions, CPW is focussed on pensions. Instead of a normal code editor, CPW uses projectional editors. These are graphical editors, in this case partly with an Excel look and partly with a timeline editor. The main difference between the two languages is that CPW seems to aim on the administration side of the pension domain, while AML aims on the product creation of life insurance and pensions.
When and How to Develop Domain-specific Languages
Mernik et al.[18] describe the rationale behind the creation of Domain-specific Languages. One of the major advantages according to Mernik et al. is that domain specific notation is beyond the limited notation offered by General Purpose Languages. This is also the primary reason for the development of the mathematical DSL in this thesis. Other advantages include that they enable reuse and easier analysis.
RISLA
RISLA is a domain specific language for interest related products[6]. Like our pensions, the base for the value of these products is the cashflow of the product. RISLA generates these cashflows from the product specification. The product specification is created to be used by domain experts. This means a more formal specification of the cashflows, that fits to the domain like the experts know in their head. The final product was used by the bank MeesPierson for all their interest products.
Discrete mathematics DSL
Our mathematical DSL is not the first DSL for discrete mathematics. Another mathematical DSL, also for discrete mathematics, is developed and includes a very large set of discrete mathematics. The scope of this mathematical DSL is very large and, contrary to our work, aims solely on the mathematical side. It provides support for sets, relations, linear algebra and many other subdomains of discrete mathematics[14]. The DSL is based in Haskell. It uses the syntax of Haskell, with added functions in a library. As Haskell allows you to decide the order of your function call and parameters, this is very much like creating your own language syntax. There is no mention of any IDE support in the article, which is included in our smaller DSL.
DSL for differential equations
Another mathematical DSL is the one described by Alnaes et al.[4]. The Unified Form Language represents formulations of partial differential equations. To be able to do this, they need a mathe-matical notation. In contrast to the work in this thesis, they have created their own constructs for these notations. The expressiveness of the language when looking at the differential equations is a lot higher than of a GPL, even though it will take some time to learn the notation in the language.
Chapter 3
Background and Context
3.1
Domain Specific Languages
This main goal of this thesis is to create a domain specific language for actuaries, that includes mathematical formulas. To be able to create this DSL, we first need to have clear what a DSL is and what the main features of a programming language are. In this chapter, we will go into the theory on Domain Specific Languages and the features that they often contain and link this to the features of the Rascal Language Workbench.
3.1.1
What is a DSL?
There are a lot of General Purpose Languages. These languages can construct any program that can also be created with a DSL. However, not all GPL programs can be written with a single DSL. A DSL is created to create programs in the described domain and nothing more. It is a more specialized language than a GPL. It doesn’t need to be able to describe every possible program that can be created, but just the programs in the domain it is in. This means that it can be more specific in what it does and it can use domain jargon to describe domain programs. This has several advantages, that are described in the next section.
3.1.2
Why DSLs?
You might ask the question why anyone wants to create a DSL. After all, a GPL can describe the DSL programs as well and these are readily available.
One of the major advantages of DSLs is that they are easier to read and validate. A domain expert can tell the programmer what to build and should be able to validate if the written code is what he needs. In the case of application domain DSLs, that are meant to be used by domain experts, this is even more the case. These DSLs allow domain experts to build their own application, which makes building applications more efficient by cutting out the programmer who does not know the ins and outs of the domain.
Another advantage has also to do with the efficiency of building applications. Because domain elements are implemented in the DSL, the programmer can write programs in fewer lines of code. Using the Actulus Modelling Language[10] as an example, the programmer can just specify a pension product by writing in what state to pay the benefit.
A third advantage, the programmer doesnt need to construct all the programs that he can think of, so having the possibility to do this only increases overhead. Someone who uses a language just to create programs in a certain domain might want the language to look more like this domain. This
programmer wants a more specialized programming language. These programming languages are called Domain-Specific Languages, or DSLs. Some of them are really popular and well-known, like SQL or HTML[19, p. 31]. Others are less well known, because they are a lot more specialized than these two, for instance RISLA, which is only applicable to the interest baring products of the financial markets. As these examples illustrate, a domain-specific language can come in many forms.
There are also some disadvantages to DSLs[19, p. 43-47]. First of all, to create a DSL requires an investment of time and money. A DSL is like any ’normal’ program: after the development phase, it needs to be maintained. As a domain evolves, the language needs to evolve with it. If not, the language will soon restrict the user in the type of programs it can create.
Another disadvantage is that DSL construction requires expertise and experience. The first DSL is harder to create than the next one and it will probably be not be the best DSL you will every create.
3.1.3
DSL Composition
As in all other programming, reuse of already created parts makes development more efficient. By reusing other languages, one can create a more extensive language with a smaller investment. Un-changed embedding is especially useful[15], as this requires the least effort. Even better would be if the host language also has a predefined construct where a language can be embedded. This would mean that new language could be created by adding a different embedded language in this construct. This way, not only the embedding language can be reused, but also the host language[15].
This section describes the decision factors for composition of two DSLs into a single DSL. In the rest of this thesis, we will use this background information to make implementation decisions. DSL Composition issues
DSL have some modularity issues, which should be handled to be able to create embeddable or composable languages. We will describe these in this section.
Concrete and abstract syntax Designing the syntax of the language is an important part of creating composable languages. Two languages that have similar constructs with different semantics in their syntax will be harder to compose without changing one of them, as the new language might not be able to see which one is used. This is not necessarily the case, as it could be that the construct of the embedded language can only be used in a construct where the construct of the host language can’t be used. However, it will complicate composition in some cases, so this needs to be considered. Type System When composing two languages, the type system of one language needs to know about the type system of the other language. For instance, when calling a function from another language, the calling language needs to know the types of the parameters it should pass and the return type of the function. The type system of the language can be composed by adding type rules of one language to the other if the embedded language is known in advance. This can lead to dependency between languages.
Generation Code generation has its own difficulties when composing two languages. Depending on the two languages, it might be necessary to rewrite generation rules or add generation rules. Next to this, composing languages might change the behavior of the code. For instance, when one language changes a file that the other language expects to remain the same, it can introduce issues.
Decision factors
To determine how to compose the two languages, we need to decide what type of composition these languages prescribe. First we will describe the two factors by which these types are defined. Next, we will describe which types of composition these factors define. Finally, we will define when to use each of these types.
Language dependency When composing a hostee lanugage to a host language, an important part of this is wheter the hostee language needs to be aware of the implementation of the host language. If this is the case, then the language is called a dependent language. If this is not the case, then this language is called an independent language.
Fragment structure When two languages are combined, this can be done in two ways [19]. Either language constructs of the hostee are used in the host language, or they aren’t. If two languages can be syntactically mixed, the language is called heterogeneous. If they are looking at the domain from two different viewpoints, then they are called homogeneous.
Types of composition
In the last two paragraphs, we have described the two factors that define the type of composition. These two factors, have two cases themselves, so they describe four types of composition [19]. These are:
• Reuse • Referencing • Embedding • Extension
Figure 3.1: Graphical view of the definition of the composition types [19][p. 117]
Reuse If you want the languages to be independent and have a homogeneous fragment structure, then reuse is they way to go. Due to the languages being independent, both languages can be reused with other languages. The languages can be kept independent by creating an ’intermediary’ language that can be hooked into the host language and is used as an adapter to create a coupling between the two languages.
Referencing In contrast to the reuse type of composition, referencing is composition of languages where one of the languages references at least one of the language constructs of the other languages. This translates to: one of the languages is dependent on the other language. In our case the ActSL language would reference the math formula construct from the MPPL language. The referencing language, ActSL, would therefore be dependent on the MPPL language.
Extension Extending a language with another language creates the opportunity to use the ex-tending languages constructs in the base language. This leads to heterogeneous fragments that use constructs from both languages. This is the composition type that we are using when using Rascal to generate code in Java. The Rascal generator is composing our ’higher-level’ language with Java. This process is called assimilation[19][p.120]. This creates a dependency where the higher level language depends on the lower level language.
Embedding In contrast to the extension type of composition, embedding doesn’t create dependen-cies between the two languages. Like the reuse type, embedding uses an adapter language to create coupling between the languages. The difference with reuse is that embedding allows syntactic mixing of concepts from both languages.
Conclusion
In this section we have described the factors that define the type of composition that should be used. In this part of the section, we will use this information to decide on the type of composition to use to compose the MPPL and ActSL languages.
The MPPL language is created to be used within multiple other DSLs. Therefore, we want the new DSLs to be able to be designed without knowledge of MPPL. As described in this section and shown in figure 3.1, language independency is achieved by using either reuse or embedding. Even though the real problematic language dependency would be a dependency from MPPL to ActSL, the dependency the other way around would oblige future developers to be aware of the syntax of the MPPL language. As we want to avoid this, we will use either reuse or embedding. As we do not use the language concepts through each other, the easiest way to compose the languages is by language reuse. This would allow us to call functions created in MPPL from ActSL, but would disallow the use of the math concepts in ActSL. One of the main advantages is that the ActSL language can also be reused with other languages. Another advantage of this is that the math preview aligns better with the math code file.
In the next section, we will describe the difficulties for this particular type of composition.
3.1.4
Language Reuse
To achieve the independency between the language, we need to avoid refences between the languages. This can be achieved by using an adapter language. This adapter mediates the contact between the two languages. The adapter language has to be defined on a per composition basis, so the adapter language that we have created is only valid for the composition of MPPL and ActSL. For a more visual description, see figure3.2.
After composition, the functions that are defined in the reused language can be used in the context language. This means that these functions need to go through the type checker and that code for the imported math should be generated when an MAPL program is generated. The rest of this section will describe how this is done.
Figure 3.2: Language plug-in point
Syntax
In language reuse, we have homogeneous code fragments. This means that we don’t use the keywords of the reused language in the context language. Referencing works using identifiers, which avoids mixing of concrete and abstract syntax[19, p. 129]. Using language reuse, we can keep the syntax of both languages clean.
Type System
As the language type systems intertwine when reusing a language, there needs to be a type system that enforces the constraints that are needed when using the two languages together. These constraints are implemented in the adapter language. The adapter language runs the constraint systems of the context and reused language, and then it runs its own constraint system, consisting of only the type system. The type system of the context language (ActSL) checks whether the reused math formula exists, and if it takes the right number and type of arguments. Finally, it checks if it returns a value that can be and is mapped to the type to which the value is assigned. To do this, hooks have been provided in the type system of the ActSL language. For this, Rascal provides the possibility to use pointers to functions as variables. Passing the necessary functions to the ActSL type checker gives us the functionality we need, without adding dependencies between the MPPL and MAPL languages. It also helps us avoid a dependency from MPPL and/or ActSL to the adapter language. These hooks can be reused by any other language that we want to combine, although at this point we can only reuse one language at a time. The extension that is allowed has to be used in a value declaration. This is the type of statement that contains the output in a ActSL program.
Code Generation
The last step in composing the languages is composing the code generators. As both languages generate code to Java, we have a simple case. However, to be able to generate the reused math formulas, the MPPL code generator needs to know how the ActSL language has been generated to Java. The MPPL code generator also needs to know the type of the generated arguments. So, opposed to the type system, this time the reused language needs to have information about the context language. For this, hooks have been provided in the MPPL code generator that allow us to pass information on how to generate the code that belongs to the ActSL language. We can again use the pointer functionality to allow the MPPL language to call the adapter language without it having to know anything about it. The only thing that is required is that the adapter language implements functions with the corresponding types and that it passes these to the MPPL code generator.
The ActSL language is able to call the math formulas. For this, it generates import statements so that the math formulas are available. The ActSL code generator is passed the available functions in these imported math files, so that it knows when to refer to the imported math.
3.2
Writing a DSL in Rascal
Rascal[16] is a Software Code Analysis and Manipulation (SCAM) solution. It is a language work-bench, with support for grammers, parsing, abstract syntac trees (AST), but also for creating IDE support in Eclipse. The collection of this functionality makes it ideal for creating a DSL. In the rest of this chapter, we will describe the necessary steps in creating a DSL in the Rascal environment. Writing a DSL is like writing a front-end of a compiler. It contains at least the following steps:
• Lexical and semantic analysis • Type checking
• Compilation to intermediary representation • Additional error checking
The following steps are added by Rascal to provide additional IDE support: • Syntax Highlighting
• Error messages • Visualization
3.2.1
Creating a compiler for a DSL in Rascal
Lexical and Semantic Analysis
To be able to compile code from a specific language, the compiler needs to understand how to read the code. As with the English language, it needs to know the words to use. This is called the lexical analysis. Rascal-MPL has support for this kind of analysis. Using the keyword lexical, the language developer can specify the lexical tokens of the language.
Next to this, the compiler needs to know the grammar of the language. This is syntactic analysis. The Rascal-MPL has support for this by using the syntax keyword.
After doing the lexical and syntactic analysis on a program, we can use Rascal to generate an abstract syntax tree for the application, which can be used in the next step of compiling the application. Type Checking
The next step in compiling an application is type checking. We need to check if all occurences of a variable are using the correct type. Rascal provides a feature that help in doing this, namely overloading of functions using pattern matching. This feature uses the fact that the higher level statements can be any one of the set of available statements. Doing this, we are walking through the abstract syntax tree depth first. Putting errors in a map referring to location will help us with showing errors in the IDE. After type checking, we can start compiling into intermediate representation. Compiling into intermediate representation
The last step for us to get a compiler is compiling the syntax and type checked code into the inter-mediate representation. The rewrite rules that Rascal allows are ideal for generating source code. Rewriting a language construct to a piece of, for instance, Java code is a very easy job using this concept. As all data types are immutable objects in Rascal, it is very important to use list compre-hensions in this step. Each concatenation to a variable would mean a copy of the variable needs to be created. Using a list comprehension would give us the performance increase by first concatenating the complete object before assigning it to an object.
Additional IDE support in Rascal
An Integrated Development Environment (IDE) contains a lot of functionality to help the developer when developing software in a supported language. examples of the functionality of an IDE are an editor, a compiler/linker, an interpreter, intelligent code completion and syntax highlighting, but there are many other features that are helpful to developers and are therefore added somewhere in the IDE. Eclipse even adds the possibility to add your own functionality to the IDE by means of a plug-in. Rascal-MPL is actually a combination of a language that is a plug-in for Eclipse. Rascal helps the user to add his own language as a supported language for the IDE. This means that the main functionality of Eclipse should also work for the newly implemented language. In the rest of this section, the IDE functionality added by Rascal is described.
Syntax Highlighting
When writing code, a very useful feature that is available in most IDE’s is syntax highlighting. This is the feature that helps the user see what the language keywords are in the code. Rascal adds this by itself from the concrete syntax of the language. Pieces of fixed text that is part of the defined syntax are highlighted as language keywords.
Error messages
In most IDE’s, when the code is incorrect, the IDE shows an icon in the sidebar that notifies the developer that there is an error message available on this position. This can be added using Rascals ParseTree annotations. Using the message annotation on a node adds an error message on the corresponding line. Using the Rascal loc type and this parse tree annotation, we can show the exact location of an error that has been found using for instance type checking.
Visualization
Rascal provides a visualization library that allows us to create visualizations of the code. This is the part that we will use for the mathematical preview. It uses the SVG support of HTML5 to create images.
3.3
Actuarial domain
The DSL that is described in this thesis is trying to describe the actuarial domain. To do this, we first need to specify the actuarial domain. This chapter is focused on a preliminary investigation on the domain.
When talking about the actuarial work, Promislow [referentie] mentions two important aspects to the work. First, the actuarial domain is based on risk. This can be for instance accident risk for car insurance, mortality risk for insurance paid on death or longevity risk for pensions and life insurance policies. This thesis focusses on life insurance and pensions, so the main risk that is dealt with is mortality and longevity.
The other basis for the actuarial domain is finance and investment. Life insurance and pensions define payments that are being postponed until a future date or future dates. This means that time is another complicating factor. Most of investment theory is based on the price that a person would expect for investing his money in something. The same goes for pensions. If a person pays for his pension, he is actually investing his money in the pension, for which he will expect a certain return. These two factors are then used by an actuary to calculate the value that is needed now to buy a payment in the future, taking into account survival rates and investment returns. Using this, the
actuary can calculate premiums, provisions and a lot other measures that are interesting. We will now elaborate on the main components of actuarial calculations. These components have a lot of options, which we will enumerate later.
3.3.1
Payment structures
Every pension and life insurances has its own payment structure. There are a couple of different pensions that I would like to explain. The following types are the most common ones.
• (Temporary) old age pension • (Temporary) spouse pension
• Risk premiums for (temporary) spouse pensions
3.3.2
Pension types
There are a lot of different pension types. Most of these are payable on life or death of the main insured. In this thesis we will show the applicability of the DSL on the two biggest pension types, namely Old age pension and Spouse pension. In this section we will describe these pension types. Old age pensions
This type of pension is a lifelong annuity for which payments start at a set age. The payment structure of an old age pension contains payments on life of the size of the insured payment from the retirement age to a certain maximum age for which the mortality rate is equal to one. The temporary variant starts at a certain retirement age and ends on a specified age before the maximum age.
PiOP = ( 0 if x + i < retirement age, 1 if r − j ≥ retirement age (3.1) Spouse pensions
The spouse pensions are lifelong annuities that start when the main insured dies. This payment on death can be seen as a payment structure with payments on death of the size of the insured payment from the current age until a certain maximum age for which the mortality rate is equal to one. The temporary variant is the same, except that it ends at a certain set age before the maximum age. Risk premiums for (temporary )spouse pensions The risk premiums are premiums that can be paid to insure a spouse pension (with lifelong or temporary payments) which is only paid when the insured dies this year, or somewhere before retirement, depending on the set coverage period. The temporary variant is the same, except that the insured payments end at a certain set age before the maximum age.
PiSP = (
0 if insured alive,
1 if insured deceased and spouse alive
(3.2)
3.3.3
Actuarial assumptions
Timing of payments
Another choice that has to be made when dealing with actuarial products is the timing of a payment. Payments could be made monthly or yearly, but it could also be a specific month in the year. Also,
there is a choice between at the beginning of the period (prenumerando), the end of the period (post-numerando) or continuously throughout the period. At my host organization, the most commonly used payment timing is continiously throughout the year. In this section, we have described the actuarial assumptions using the postnumerando variant as an example.
Mortality risk
As mentioned before, the most important type of risk for life insurance and pensions is mortality risk. For static calculations, like provisions, premiums and even cashflows, this risk measure, plus the interest rates and the payment structures, suffice to be able to calculate the expected values. Both mortality risk as longevity risk is influenced by the mortality rates of the population. There have been some types of mortality estimations that we need to address to accurately describe the history (and present) of the actuarial domain. First, there were the commutation tables, which describes the number of living persons of a group of zero year olds at each age until the population has decreased to zero. These create the flat mortality tables that dont take the improvement in mortality rates that can be seen in historical experience. examples of these rates can be found in the GBM/V mortality tables issued by the actuarial society in the Netherlands, Actuarieel Genootschap (AG)[11].
Next, we have the deterministic models that do take these improvements into account, but dont take into account uncertainty about this improvement. These deterministic rates extrapolate the historical improvement in mortality rates to fixed mortality improvements per age per year. examples of these rates can be found in the Prognosetafel [12] mortality tables issued by the AG from 2005 until 2014. The next step in the improvement of estimations of mortality is the stochastical mortality. AG is issuing these on the 9th of September in 2014. These will be described by a stochastical model, which would better show the uncertainty in the improvement of mortality rates in the future[referentie]. The example formula below shows how the mortality rates are used .
tpx= t−1
Y
i=0
(1 − qx+i)
Figure 3.3: Calculation of chance that participant of age x is still alive at timepoint t
Partnerfrequencies
A spouse pension is paid on death of the insured. However, as often not all insured participants have a partner, not all spouse pensions will have to be paid. As the provision should mirror the expected value of the pension, this should be taken into account when calculating the pension value. Pensionfunds can decide on their own expected partnerfrequencies. In the Netherlands, there are two common partnersystems. One translates to Known, and the other Unknown. The Known partnersystem is the prudent one. It assumes that at this point, everyone who is insured has a partner. The Unknown partnersystem uses a predefined percentage of insured that have a partner. These are often different per age and gender.
Interest/Investment return
The other main component used in calculations for actuarial products is the interest. When calculating a present value of a life insurance product or pension, the actuary takes into account that during the time until the payments need to be made, the insurer can invest the money it has now and get an investment return. The buyer of the product will expect a certain amount of investment return on his
premiums, otherwise he would be better of investing it himself. This investement return is therefore a part of the actuarial domain.
In most cases it will be used after the expected payments are known. An example of a formula is shown below. The example shows the calculation of a provision for old age pension, when the expected future payments are calculated like in example.
P VOP = maxduration X i=0 CFOP i (1 + ri)i+0.5
Figure 3.4: Impact of interest on actuarial lumpsum[13, p. 194]
3.3.4
Actuarial calculations
In the previous section, we have described the most important actuarial assumptions that are used by actuaries to estimate the chance that a payment has to be made at a certain point in the future. All values that are calculated for a pension are somehow related to the expected payments that are made in the future. This is what is called the cashflow of a pension and it is the basis for all actuarial pension calculations. For this reason, to prove our DLS works, we are going to create a cashflow application using MAPL. In this section, we describe how to calculate these cashflows for old-age and spouse pensions.
Old-age pension cashflow
The cashflow for a postnumerando old age pension is already described in the previous section. In this section we have included the equation for a continuous old-age pension. The old-age pension cashflow is the simplest calculation in the pension actuary´s domain.
CFt=t−1px∗ 0.5 ∗ PtOP +tpx∗ 0.5 ∗ PtOP
Figure 3.5: Expected payment for a insurance on life of main insured[13, p. 194]
Wherenpx= n−1px× (1 − qx+n−1) and qxis the mortality for a x-year old insured.
Spouse pension cashflow
For the cashflow of a spouse pension, there are a couple of additional things to take into account. This is a pension on two lives, where the payment is made when the main insured dies before the coinsured does (see3.3.2for formal specification).
CFt= CFt−1∗ (1 − qy+t−1) +t−1py∗t−2px∗ (1 − qx+t−1) ∗ 0.5 ∗ bt+tpy∗t−1px∗ (1 − qx+t) ∗ 0.5 ∗ bt
Figure 3.6: Expected payment for an annuity insurance paid on death of main insured [13, p. 194]
Provision factor
The provision is the present value of the expected future pension payments. The provision factor is the present value of the expected future pension payments if you have a pension benefit equal to 1. For the postnumerando old-age pension with retirement age 65, an example is shown below.
65−xax= 130−x X t=65 t+1px (1 + rt)(t+1)
Figure 3.7: Provision factor for an annuity insurance paid from retirement age until death at the end of each year
Additional factors to take into account include difference in age between main and coinsured, which in the Netherlands is often assumed to be a certain number of years equal for everyone. In most cases the male is assumed to be three years older. We will leave the possibility for the actual age difference in the DSL as it seems to conform to the AML specification.
Chapter 4
MPPL: a DSL for discrete
mathematics
The Actuarial DSL is going to be built in Rascal MPL. This language workbench is a plug-in for Eclipse. To be able to create the mathematical side of this DSL, we are going to need a way to input mathematical formulas. There are two popular standards[reference] for displaying mathematical in-put, namely the MathML and LaTeX/TeX markup languages. These languages are actually DSLs for (mathematical) typesetting. At the Faculty of Economics and Business (FEB), students are required to write their thesis in LaTeX. Due to this, young actuaries are already trained in the use of the LaTeX language. It would therefore be most convenient, if an actuarial programming language would build on this training.
The American Mathematical Society has created an extension to LaTeX to add mathematical notation to the typesetting language. This package, called AMS-LaTeX, is the main mathematical typesetting extension in LaTeX. To provide users with the opportunity to create their own formulas, the package adds keywords and the syntax that is necessary for these formulas. For more information about the AMS LaTeX package we refer you to the AMS LaTeX User Manual[5].
4.1
Syntax
The subset that is implemented is only the part that is necessary for implementing most of the actuarial formulas. As these are often discrete and sums of previous or future years, integrals and differential equations have been left out of this subset. In this section we describe which mathematical constructs are implemented. This is the syntax of our mathematical DSL. This is needed to know how to write a formula in the mathematical DSL, but also to get a grasp on why certain elements have been included.
4.1.1
Formula
The main building block of the DSL is a formula. All lines in a MPPL file are either blank or contain a formula. A formula In the image below you can see the simplest example of a formula in MPPL.
4.1.2
Sum operator
To be able to create most actuarial formulas, we have implemented a sum construct. In the AMS-LaTeX package and our mathematical DSL, this operator is equal to \sum. The only use of this that is allowed is the version with a start index and final index defined. The code to use this operator is \sum {i=...}ˆ{...}, where i can be any variable name. The displayed equation can be seen below.
...
X
i=...
(4.1)
4.1.3
Product operator
As seen in section ??, to be able to calculate the chance that a person is still alive at a point in time, we need a product operator. In the AMS-LaTeX package and our mathematical DSL, this operator is equal to \prod. The only use of this that is allowed is the version with a start index and final index defined. The code to use this operator is \prod {i=...}ˆ{...}, where i can be any variable name. The displayed equation can be seen below.
...
Y
i=...
(4.2)
4.1.4
Basic math operators
Almost all mathematical functions contain one of the basic math operators ∗, /, + and −. The divide operator (/) can be written with two different constructs in AMS-LATEXand our DSL. You can either
use / or \frac{...}{...}. The displayed equations are shown below.
a/b (4.3) a b (4.4) a ∗ b (4.5) a + b (4.6) a − b (4.7)
4.1.5
Vector indexing
In our mathematical notation, we want to be able to use subscripts to show the indices that need to be used for certain variables. Most variables that are used in the actuarial formulas are dependent of the time variable t, for instance, the mortality rate is often notated as q with subscript t. This indexing is accomplished by using the variable index constuct. The displayed equation is shown below.
qt (4.8)
4.1.6
Powers
Another common part in mathematical formulas is the use of powers. In our actuarial formulas, these are used, for instance in the discounting factors. In AMS-LaTeX and our mathematical DSL, these are accomplished with the aˆ{b} construct. See below for the displayed equation.
Cases
The last part that is less commonly used in regular mathematical formulas, but is very interesting and necessary for actuarial formulas is the case operator. This operator allows us to make a dis-tinction in the formula depending on for instance time. In a actuarial perspective, this might be a different formula before the retirement age than after. This construct consists of multiple parts. The \begin{cases} .. \end{cases} indicates that a case distinction is going to be made. Then for each case a statement with the following syntax is expected: formula in case & \text{if } condition \\. The displayed equation contains an example of a case formula.
(
qt if t ≥ retirementAge
qt−3 if t < retirementAge
(4.10)
4.2
Type checker
MPPL knows only a couple of types, which can be split into three groups.
• Single variables - these can be either integer, double, or of a compatible type in the composition of two languages
• Array variables - these can be arrays of either integer, double, or of a compatible type in the composition of two languages
• Object variables - these are part of a language that reuses the MPPL language
The variables that are used should be checked for consistency with these types. This is done in four steps, namely checking for duplicate declarations, ambiguous use of a variable, for unused variables and for undeclared variables. Any errors that are found in the function are annotated in the code editor.
4.2.1
Duplicate declarations
It is important that functions and variables within a single function are not declared multiple times. This would lead to ambiguous function calls by either the composition language or the math program itself. The type system checks for duplicate declaration of variables in sums, products and formula declarations.
Figure 4.2: An example of a duplicate declaration
4.2.2
Ambiguous use of variable
The first step is checking that a variable is not used in ambiguous ways. This means checking that a variable is not used as multiple types in the same formula. For instance, a variable can not be used as a single and an array variable. Next to this, object variables can not be used with and without a property call. The composing language could provide a default function to use to get a value from a object variable, so that the object variable can be either a single variable or an array variable. In that case, the property functionality of the object variable is forfeited.
Figure 4.3: An example of an ambiguous use of variable
4.2.3
Undeclared variables
The next step is checking if all variables are declared. This step checks if all variables that are used are either part of the function declaration or are declared in the enclosing sum or product. As the type checker of the MPPL language has no knowledge of a composing language, it does not check if the properties used on object variables are defined.
Figure 4.4: An example of an undeclared variable
4.2.4
Unused variables
Finally, warnings are provided when variables are defined in the function declaration or in a sum or product, but are not used in the formula. This could indicate that the language user has made a mistake in his formula, but it could also be intentional, for instance when calculating ten times ten using a sum. As this would not be very effici¨ent, we warn the user that the variable has not been used.
Figure 4.5: An example of an unused variable
4.3
Evaluator
When MPPL is used as a separate language, instead of in combination with another language, you want to be able to evaluate the functions. For this, MPPL contains an evaluator. The evaluator can be called from the Eclipse context menu for MPPL. It asks for a function and the parameter values and returns the evaluated value. An example of the use of this evaluator is shown in the images below.
Figure 4.6: An example of inserting a single value and a vector value
Figure 4.7: An example of the output the evaluator
4.4
Preview
A mathematical DSL is useful due to the widely known notation of math. This notation is nothing like the constructs that are described in4.1, but consists of mathematical operators and Greek letters like shown in the displayed equations in4.1. The Eclipse editor doesn’t allow these symbols, which makes it hard to be able to write the mathematical functions in the editor. Our solution to this is a live preview, that allows the user to write the more elaborate AMS-LATEXnotation, but shows the
compiled AMS-LATEXin a preview. This is a similar approach as the one taken for instance by an
existing Emacs plug-in[1]. An example of this preview is shown in the image below. Figure 4.8: An example of our math preview
4.4.1
Code Generator
When using this DSL by itself, the user should be able to generate a program from the MPPL code. As our development environment is set up for use with Java and Rascal, we generate code for the mathematical formulas in Java. The code generator generates the formulas, including a console front-end to be able to call the formulas and provide input. The functions can also be called from
another program, but inputs are assumed to be either double, integer or arrays of doubles or integers, depending on the usage in the formula.
Chapter 5
MAPL : A DSL for pension
calculations
5.1
Design
This section describes the syntax of the MAPL language. Most of this is equal to the design of the Actulus DSL of the University of Copenhagen[10]. This DSL accurately describes most of the actuarial domain as described in 3.3, but some parts where missing from the design in the article. The DSL did contain the four most important elements of any specification of an actuarial product. These are the statemodel, riskmodel, product and the calculation basis.
5.1.1
State model
A pension or life insurance product is dependant on the state of the life of the insured. For instance, an old age pension is payable from a certain age until the state of the life changes from alive to dead. This is defined in the state model, which consists of the states (i.e. alive, dead) and the possible transitions from these states. This state model can be defined in AML as shown in the code listing below.
statemodel L i f e D e a t h ( p : Person ) where s t a t e s =
a l i v e dead t r a n s i t i o n s =
a l i v e −> dead
Listing 5.1: example statemodel AML[10]
The main purpose of the state model in the MAPL language is to check if the product that has been created is consistent with the states and transitions that are available in the code for the program. We will further describe this in section ??.
5.1.2
Risk model
As we have explained in the previous section, the state of the insured and/or coinsured is very important to be able to value the product. In addition to defining this state, we also should be able
to define how someone’s state will change from one state to the other. This can be done by describing the risk model. This risk model can contain more than one state transition. In the example below we have shown a single state transition. This is a state transition that can be seen in a single-life insurance product.
riskmodel R i s k L i f e D e a t h ( p : Person ) : L i f e D e a t h ( p ) where i n t e n s i t i e s =
a l i v e −> dead by P r o g n o s e T a f e l 2 0 1 2 2 0 6 2 ( p ) Listing 5.2: example riskmodel AML[10]
The PrognoseTafel 2012 2062(p) in the example above is a function that has been defined in an external library. This function returns the intensities for the alive to death transition. An intensity defines the number of occurences of an event in a certain way. In MAPL, a risk intensity defines the probablility that a certain state change occurs. In the example above the probability that someone dies is defined by the Prognosetafel 2012-2062.
5.1.3
Product
To be able to calculate actuarial values for a pension, the most obvious part of the calculation is of course the product itself. This product can be defined by declaring when payments have to be made. In AML, this can be defined in a very clear and intuitive manner.
In example #1, we have defined an annuity. The at t contruct indicates that this is an annuity[10, p. 10]. The product contains conditions that need to be satisfied when the payment is done. In example #1, the insured should not be in the state dead and the date t should be later than the date r. This condition is put into the provided(...) construct. This construct contains the conditions that should be satisfied to start or continue the payment of the product.
In example #2, the product is a lumpsum. The when(...) construct defines a event that defines the moment at which the lumpsum is paid. In this case, the lumpsum is paid at the transition from alive to dead.
product L a t e n t A n n u i t y ( p : Person , r : TimePoint ) : D i s a b i l i t y ( p ) where o b l i g a t i o n s =
a t t pay $1 p e r y e a r p r o v i d e d ( n o t dead and t >= r ) Listing 5.3: example product #1 AML
product L i f e I n s u r a n c e ( p : Person ) : D i s a b i l i t y ( p ) where o b l i g a t i o n s =
pay $1 p e r y e a r when( a l i v e −> dead )
Listing 5.4: example product #2 AML
5.1.4
Calculation Basis
As specified in sections3.3.3and3.3, a common life insurance product needs at least a mortality rate and an interest rate to be able to calculate provisions. These attributes are the actuarial assumptions. These are not part of a product, but decided upon per pensionfund. In AML these attributes are defined in the calculation basis[10, p. 9].
riskModel = R i s k L i f e D e a t h ( p )
interestRate = ( t : TimePoint ) => 0 . 0 2 endDate = p . B i r t h D a t e + TimeSpan ( 6 0 , 0 )
Listing 5.5: example calculation basis AML
In the example, the basis contains three properties. These properties can be used in the calculations. A property consists of a property name and its value. These values can be either pointers to one of the models (i.e. riskModel ), expressions (i.e. endDate) or inline functions (i.e. interestRate).
5.1.5
Declarations
To create a full program, we need to have variables that can be used outside of the models. These contain for instance the results of the calculations, but they can also be used to store the information of the insured in, via the Person type. This information is needed by all of the models to be able to define the product. This functionality is available in MAPL through the value construct. In the example below, we show the declaration of an insured man named John Doe.
value j o h n : Person = Person ( ” John Doe” , TimePoint ( 1 9 7 0 , 1 , 1 ) , Female ) Listing 5.6: example declaration AML
This is also were we can use the mathematical DSL. In the example below, we show the use of a function named Ax in an imported mathematical function. We use a declared value myBasis that contains a basis and a declared value calcDate that contains a TimePoint.
value p r o v i s i o n : Money = Ax( c a l c D a t e , myBasis . l i f e i n s u r a n c e , myBasis . r i s k s , myBasis . i n t e r e s t ) Listing 5.7: Example use of math MAPL.
5.2
Example program
Now that we’ve described the different parts of the MAPL language, we can create our first program. In the example in figure 5.1, you will find a program that calculates a provision for a whole-life insurance product that pays one dollar a year, until the insured is no longer in a state alive. The calculation date is defined to be January 1st, 2015. We have also added comments to the code to clarify and to show how we can comment MAPL code.
Figure 5.1: Example MAPL program code.
5.2.1
Execution
The MAPL language has a code generator that generates Java code. The user can access the values that are declared. The code from listing5.1 compiles to a Java program with the console front-end
