Home »

Resources » Here

As far as supply chains are concerned, a

*periodic* forecast refers to the traditional demand forecast where the values are computed according to a period, usually a day, a week or a month. While we usually recommend using probabilistic demand forecasts whenever they are applicable, there are some situations where periodic forecasts are acceptable. The

*periodic* forecasting mode of Lokad is intended to generate daily time-series forecasts.

## General syntax

The forecasting engine has a function dedicated to periodic daily forecasts. The syntax is as follows:

// 'T' is of type [Id, *]
table T = forecast.periodic(
hierarchy: H1, H2, H3, H4
category: C1, C2, C3, C4
horizon: 56 // number vector in days
present: (max(Orders.Date) by 1) + 1
demandDate: Orders.Date
demandValue: Orders.Quantity
censoredDemandDate: OOS.Date)
show table "Periodic" with Id, T.ForecastDate, T.Mean, T.Sigma

The table

`T`

returned by the forecasting engine does not have the type

`[Id, Date, *]`

but the type

`[Id, *]`

instead. This is a stipulation imposed by Envision, and dates, as they exist in the `Day` or `Week` table, cannot be introduced dynamically during the execution.

The

`horizon`

argument is a number vector - or just a scalar number - that can be defined for each item. The horizon is expressed in days. The forecasting engine does not have any dependency on the horizon: using a longer horizon does not have any impact on earlier forecasts. The horizon is only used to truncate the forecasts and keep the verbosity of the results under control.

The other arguments are identical to their counterparts that we previously introduced with the

probabilistic demand forecasts.

The daily values

`T.Mean`

returned by the forecasting engine are fractional, possibly smaller than 1. Under the hood, the forecasting engine uses probabilistic forecasting models that are projected as their daily averages.

Each daily value is also associated with

`T.Sigma`

, which represents an estimation of the square root of the variance of the forecasts. The variance is obtained as the

second central moment similarly derived from the probabilistic forecasting model computed by the forecasting engine.

## Mean squared error

The daily periodic forecasts computed by Lokad are optimized against the

mean squared error (MSE), which is used as the loss function by the forecasting engine. Intuitively, through this loss function, the forecasts are expected to be

*balanced*: the mass of the over-forecasts should be equivalent to the mass of the under-forecasts.

It is notable that using the MSE as a loss can generate fractional values for the demand forecast. Thus, for example, the projected daily demand for a slow mover can be a value between 0 and 1.

The forecasting engine generates

*average* daily forecasts, which should not be confused with

__median__ daily forecasts. Median forecasts are also balanced, but in a slightly different way: the balanced median forecasts have 50% chance to be above or below the future demand while

*average* forecasts have 50% of the mass above or below the future demand.

## When to use daily forecasts

Periodic daily forecasts do not work well with either intermittent demand or erratic demand. This limitation is a direct consequence of the very nature of the periodic daily forecasts rather than being a limitation of the forecasting engine itself. Indeed, by design, the daily averages do not convey much information about the demand uncertainty itself. The estimated variance, which is also returned by the forecasting engine, does somehow mitigate this problem a bit, but the mitigation remains shallow.

Thus, as a rule of thumb, we suggest not using the

*periodic* forecasting mode if the input time-series do not have about 10 units per day on average. Below 10 units, native probabilistic forecasting approaches invariably deliver superior operational results.