Advanced Units

How to use Units to describe additional information

Overview

In addition to the the straightforward examples on the previous page, Models applies factors, and concepts of time and context to Unit Parts.

Unit Factors

It is common for models to change between different "sizes" of unit.

For instance, a financial model for a large company may have a "standard monetary unit" of $000. This means that, unless otherwise specified, all monetary figures are in thousands of US dollars.

Some Variables may need to be specified in a different unit, e.g. the price of a product may be in single US dollars ($).

Unit Factors in Models allows you to move between different factors within the same Model, without needing to specify different versions of the same Unit.

Read more about how to use Unit Factors here.

Balance vs. Flow

The concepts of Balances and Flows are commonly used in financial modelling (you may also have seen the term Stock used instead of Balance).

An example of a Flow is my annual wages - how much money I have coming in each year. A Balance is the amount of money I have in my bank account.

A Flow must relate to a period of time (e.g. a day, month or year), whereas a Balance is a snapshot at a point in time.

In Models, this concept is captured within a Variable's Unit, which allows Models to infer more context about a calculation. Models applies the following rules:

• Adding a Balance to a Balance gives another Balance

• Adding a Flow to a Balance gives a Balance at a later point in time (see Time Offsets)

• Adding a Flow to a Flow gives another Flow

Time and Time Offsets

Units also hold information about time.

Imagine you want to calculate the number of members who leave your gym business each year (called Churn), you would do this by applying a Churn rate to the number of customers at the end of the previous year: Churn = Members [-1] * Churn rate.

Now let's say I have an Assumption representing actual churn rate in 2021. The Unit for that Assumption would be Member [Flow, 2021] / Member [Balance, 2020].

Without these details in the Unit, we would probably label our Assumption as Unitless, 2021, which would exclude important information about the assumption and pose several questions: Does 2021 relate to the churned customers, or the starting balance?; What is being churned?; Is the Assumption a Flow or a Balance? (answer: it is a combination of the two).

Including time information in the Unit answers these questions in a concise format.

When creating the Unit for a Variable, it is rare to use specific dates - each Unit Part has a Time Offset defined, such as This Period, or Offset [-1]. Any Assumptions created for this Variable will then have specific dates applied to their Unit based on the Timings of the Model. See the next section for more details on defining Units.

Constants

Units can also be defined as Constant, either as Constant (Flow), or Constant (Balance), to indicate values that are unchanging over time.

Context (Unit Modifiers)

Just as we add information about Time to Unit Parts, we can also add information about Context by using Concrete Tags.

Context Tags act as a modifier to the main Abstract Tag of the Unit part.

For instance, if we have a data point representing the population of the United Kingdom at the end of 2022, we would give it the Unit Person [Balance, 2022, UK] where UK is the Tag for the United Kingdom.

Taglo interprets this Unit as Person relating to the UK [Balance, 2022].

This allows Taglo to infer relationships between different data points based on their Units.

For instance, let's say we have the following data points: Person [2020, UK], Person [2021, UK], Person [2022, UK], Person [2021, France], Person [2021, Spain](all Balance Units).

In this case, Taglo can identify two series from this data: 1) the UK population, changing over time from 2020 to 2022; 2) The population in 2021 of three countries, the UK, France and Spain. It can identify the second series by virtue of the fact that the UK, France, and Spain Tags all have Country as a parent.

This method of applying Context to Units avoids the completion of multiple bespoke fields when entering data. You don't need to define a time field, or a country field - just include the Time and Context in the Unit.

This is particularly powerful for Compound Units, where the Context of one Unit Part might be different from another.

For instance, I might have data representing the ratio of one country's GDP to another, in USD. e.g., USD [UK] / USD [USA], and USD [France] / USD [USA].

Normally, I might choose to call these data points Ratio of GDP to USA GDP, and then include a Country field for the country I'm comparing (UK or France).

But what happens if I introduce a third data point, USD [France] / USD [UK] to my dataset?

I would have to call it Ratio of GDP to UK GDP. The information about the country I'm comparing France to is hidden in text, and software can't infer a relationship about the two France ratios (one to the USA, and one to the UK).

One solution is to have two extra fields: Compared country and Compare To country. It doesn't take too much imagination to see that this could soon become unmanageable, and more importantly, not useful. By adding Context to Unit Parts, we take care of this problem.