Get Inspiration for New Problems

In my last post and debut podcast, I talked about why strong foundations matter for coming up with smart, workable solutions in business. But, there's a twist when we hit a problem that's completely new to us: just having that solid base isn't always enough.

This brings me to a story I love to share with my team and my training participants, about how Henry Ford had a lightbulb moment that changed cars forever. Did you know he got the idea to build cars faster and cheaper by watching how meatpacking plants worked? They had this assembly line where everyone did one job, moving the product along quickly. Ford thought, "Why not do this with cars?" And just like that, in 1913, he changed the game by setting up an assembly line at his car plant in Michigan.

Theory & Practical

After completing the actuarial modelling class on Tuesday, I had a short but fruitful conversation with my team member, Koh Ying, at the lift lobby. As this was a developer course, Koh Ying came over to support the training and provided guidance to the participants when they encountered challenges in the class exercise.

Well, the topic we discussed might seem a bit dry, but it is important to our work - yes, we discussed why we should learn the fundamentals/concepts, or which I usually call "theory".

Some Thoughts on Prophet (Part 2)

One of my favorite functionalities in Prophet is "parameterized extended formula". Although this technical term sounds a bit complex, the concept is in fact pretty straight forward - we can just relate to something we learned in the secondary school, i.e. "f(x)" (functions).

How parameterized extended formulas work is similar to self-defined function in Excel VBA. Say we have a function with multiple elements, e.g. f(x, y, z). When we input x = 2, y = 3 and z = 4 to this function, we may get a value of 10 directly. The same function can be used for different combinations of x, y and z - i.e. we can REUSE the function and make our calculation models more efficient.

We can use parameterized extended formulas for various areas, such as converting annual decrement rates to monthly rates. Instead of replicating similar formulas for death, TPD and CI separately, we can create a parameterized extended formula that can be used for death, TPD and CI at the same time:

1. Create an extended formula that contain (say) 3 elements, say I call it as EXT_FORMULA.
2. Create different extended formula for death, TPD and CI. Just one line code, #EXT_FORMULA(x, y, z) (it's hash-E-X-T-underscore-F-O-R-M-U-L-A). Say the extended formula for death is DTH_INPUT.
3. To get the value from EXT_FORMULA, we need to specify the variable that carries values of elements, such as DTH_INPUT.QX (QX is a public variable under EXT_FORMULA).

Another reason I love using parameterized extended formula is it allows multiple outputs from the same extended formulas. For example, in case we have two separate public variables for male and female, we can define two public variables within the same parameterized extended formula, i.e. we can directly get the values from the variable by specifying (say) DTH_INPUT.QX_M and DTH_INPUT.QX_F.

You can also have numeric and text public variables at the same time. Both numeric and text public variables may appear as array variables if needed.

Further reading:

• Some Thoughts on Prophet (Part 2) (This post)
• Some Thoughts on Prophet (Part 1)

Some Thoughts on Prophet (Part 1)

Sharing is always a good thing. By sharing the knowledge I have, apart from providing others some ideas on how to improve their daily work or resolve the problems they encounter, I can still benefit from the sharing. Through writing posts in LinkedIn, I strengthen my knowledge and concepts, as well as gaining some inputs and view from other connections in my network.

For better records, I also put down my sharing under this blog, so that it is easier to be referred if needed.  

Thought (1): Debugger License - Get it if you have the budget

If you have additional budgets on Prophet licensing, I would suggest to get the Debugger license (yes, it needs a separate licensing). When you encounter errors in your Prophet runs, AND Prophet cannot display its run log (i.e. errors in both doing runs and displaying run logs at the same time) , Debugger will save your life (otherwise it may very tough to find out what the issue is).

If I can suggest enhancements on Prophet, I think it will be great if we can allow t-dependent calculation for TEXT variable as well. At the moment, Prophet doesn't allow t-dependent text variables - which create some hassles especially when we want to change the text values for different calculation loopings (CALC_LOOP).

P/S: We can also use PRINT_TO_FILE to output variables that we want to check into run logs.

Thought (2): No t dependent for text value?

To overcome this limitation, of course there is more than one way to handle it. For example, if the text value is a table name, we can vary the table names within READ_GENERIC_TABLE, under the numeric variable that we want to store the value read from the table.

Another approach I use quite a lot is using an extended formula to read the text value (it's OK to make the public variable within the extended formula to vary by calculation looping). Usually I will use ONE extended formula to read many text variables at the same time (so that can reduce no. of variables).

Of course, if you don't have debugger license, it is not easy to check text the value as it cannot be exported to normal text variable.

Further reading:

• Some Thoughts on Prophet (Part 2)
• Some Thoughts on Prophet (Part 1) (This post)

How do You Setup Indicators in Your Prophet Model?

In my previous post, I have discussed areas that you may consider in setting up input variables. Before I proceed my discussion on core variables, I would think that it is good for use to take a look on indicators - as indicators play an important role in setting core variables with various formulas (known as "variable definitions" in a Prophet model). 

The funny thing about indicators is: it DOES NOT carry any formulas that you need to use in calculating a variable! Basically, they are just some texts that you can combine using different logical operators (AND, OR, NOT), such as "ORD_PAR AND SING_PREM" for a single premium ordinary participating product. 

Know More About Input Variables

If you a Prophet user, you must have heard about input variables and core variables. In simple words, input variables that you need to define individually when you setup a product (of course you can accept the default definitions), whereas core variables are those will be automatically called from libraries when you perform a run. 

However, do you ever think how we should assign a variable as input variable or core variable? What are the characteristics that make a variable to be better assigned as input variable?

There is no a single right or wrong answer for the above questions. In this article, I am going to share my views (actually the treatment I adopted in the Prophet models I developed before) on how you can handle input variables in the Prophet models.

Master Products in Prophet Workspace - Many or Few?

When I worked on Prophet projects that involved setting up Prophet model from scratch or streamlining existing Prophet models, one of the common requests I came across was relating to no. of master products. Many Prophet users have such a perception, i.e. the lesser no. of master products in a Prophet workspace, the better it is.

Let's think about it, is this perception correct? When we are talking about of having a better Prophet model, what does the word "better" mean?

Define a BETTER Prophet Model

It is important for us to define what we expect from a "better" Prophet model, instead of focusing on the no. of master products in the model. Let me share some views if I am a Prophet user: