As background, I would point you to my online forecasting textbook where we have a chapter on foundation models (Hyndman et al., 2026). Another excellent reference on this topic is Christoph Bergmeir’s paper “LLMs and Foundational Models: Not (Yet) as Good as Hoped” (Bergmeir, 2024).

1. How significant a change do time series foundation models represent for the practice of forecasting?

They’re a real shift in how forecasts get produced, but not yet a demonstrated shift in how accurate forecasts are in general. The genuine change is architectural and operational: instead of building, tuning and maintaining a separate model for every series, an organisation can point a single pre-trained model at a new dataset and get a forecast with no dataset-specific training or model selection. That lowers the barrier to entry for forecasting at scale, particularly for teams without in-house statistical expertise.

What it hasn’t yet done is replace the case for careful statistical modelling. The strongest independent critique of the field is Bergmeir (2024) who found that when you check the reported empirical results, the performance is often nowhere near as good as claimed. Often the statistical benchmarks are implemented poorly, or missing altogether, or highly selective. So these foundation models are an important development, but they are not close to being the panacea that many of the companies behind them are claiming.

2. How should organisations compare foundation models with well-tuned statistical or task-specific approaches, particularly considering accuracy and cost?

First, make sure the statistical baseline is actually well implemented. This is the single biggest problem Bergmeir (2024) identifies in the foundation-model literature: papers routinely compare against under-tuned or de-ensembled versions of classical methods, then claim victory. So I would be asking: what exactly were the statistical benchmarks, how were they tuned, and were they given the same advantages (ensembling, proper cross-validation) as in the studies that established them as strong benchmarks in the first place?

Second, evaluate on your own data with proper rolling-origin backtesting, not on a vendor’s leaderboard, or even a public community leaderboard. Public benchmark scores are increasingly unreliable as measures of genuine out-of-sample skill because the data used in comparisons was also used in training. This “leakage” is a growing problem – see Meyer et al. (2025) who found that of 401 datasets used across 22 published time-series foundation models, only 6% had never appeared in any model’s pre-training or fine-tuning corpus. Also, historical series that are not in the training data can be correlated with series that are in the training data due to being subject to the same environmental shocks (e.g., COVID). So even if there is not direct leakage, there can be indirect leakage induced by correlations. Therefore, these comparisons on historical data are not a great guide to what the models will do on new data.

Third, weigh total cost, not just error metrics. Well-implemented statistical models (ETS, ARIMA, Theta, and simple combinations of these) are cheap, transparent, fast, and easy to explain. Foundation models bring inference cost, latency, hosting/vendor dependency, and limited interpretability. Even if the accuracy gain over a well-tuned statistical model is real, the operational cost may not be worth it.

3. What do current benchmarks fail to tell us about how these models will perform in real production settings?

1. Public leaderboards report an aggregate score across many datasets and domains at once, which can hide wide variance in performance on the specific kind of series a given business actually needs to forecast.
2. As noted above, they carry a real contamination risk which may render the benchmark unreliable.
3. Benchmarks rarely report the things that determine whether a model is usable in production: inference latency at the volumes a business needs, hosting and total compute cost, robustness to structural breaks and regime changes, how the model handles exogenous variables and irregular/missing data, and how failures are detected and explained when they occur. A model that tops a MASE leaderboard by a small margin but takes an order of magnitude longer to run, or performs poorly on genuinely new data, may be the wrong choice operationally even if it’s the “best” model on paper.

A researcher portal is a website that attempts to list all the publications of a given researcher, and calculate citation statistics, etc. Every researcher wants their work read and cited, so these websites can be useful tools for getting your work noticed. Conversely, they can be a good way to find new work by researchers in your field.

Going in the other direction, here is my family tree, compiled from the Mathematics Genealogy Project (MGP). Each person advised the one below them. Hover over a portrait (or tap it) to see who they were.

Many people have two or more advisors, so there are multiple “lines of ascent” (as there are with regular family trees). I am showing two of many possible ancestry lines here, which happened to reconnect in the 1600s.

I was wondering if mathematical relationships exist between monthly, quarterly, and annual growth rates (percentage changes). For time series data …
1) Is there a mathematical formula to know by how many months the Month-to-Month changes lead turns in this-month-to-the-same-month-one-year-ago changes (annual changes)?
2) Is there a mathematical formula to know by how many quarters the Quarter-to-Quarter changes lead turns in this-quarter-to-the-same-quarter-one-year-ago changes (annual changes)?
Also, regarding simple moving averages/totals:
3) Is there an exact or approximate formula to know by how many months a 3-month simple moving average (or moving total) leads a turn in a 12-month simple moving average (or moving total)?
As an example: Inflation is typically measured with Y/Y percentage changes in the CPI. So, it would be helpful to be able to identify when the 12-month rate of change will likely reach a top or bottom, using the 1-month or 3-months rates of change.

Women in Forecasting was created to showcase the important contributions women are making to time series forecasting, a field where women remain underrepresented. Beyond the talks, the conference is also an opportunity to build community, foster professional connections, and support mentorship for those entering the field and those advancing in their careers.

I’m delighted to see four of my own former PhD students are invited speakers at the conference, along with Mariana Menchero who was a great help to me in solving numerous technical issues related to the Python edition of FPP.

Date: Saturday, June 27

Venue: Université du Québec à Montréal (The same venue as ISF 2026)

Registration is required for both the in-person venue and on the Zoom.

Register for the WIF Conference: https://wif.nixtla.io/

About a year ago, we did a soft launch of the online edition of “Forecasting: Principles and Practice, the Pythonic Way” (FPPPY). In this latest edition of the FPP book, George Athanasopoulos and I are joined by four additional co-authors: Azul Garza, Cristian Challu, Max Mergenthaler and Kin Olivares. Our new co-authors are Python and forecasting experts, and have all been involved in developing the open-source Nixtla software that is used throughout the book.

Since the online edition was launched, we have made numerous small updates and improvements to the book, ironing out errors, improving the presentation, and simplifying the Python code where possible. Now it is available in print as well!

The first 13 chapters of the Python edition closely follow the corresponding R fpp3 edition, but with code examples in Python rather than R. We have also included two new chapters: Neural networks and Foundation forecasting models, which are dedicated to recent techniques and developments in neural networks applied to forecasting.

As with previous editions, all code and examples are fully reproducible, and exercises are provided for teaching or self-study. The online edition will remain free, and will be updated as needed. The print edition is available for purchase, and we hope it will be a useful resource for students, practitioners, and anyone interested in learning about forecasting with Python.

Updated: 23 April 2026

Here’s the blurb (not written by me):

Data scientists today are under pressure to adopt the latest tools - machine learning, LLMs, generative AI. But in the rush to embrace what’s new, many are leaving some of the most powerful analytical tools sitting on the shelf. Tools that handle something modern AI largely can’t: uncertainty.

In this episode, Prof. Rob Hyndman joins Dr. Genevieve Hayes to make the case for why rigorous statistical thinking remains indispensable in the age of AI, and what data scientists are giving up when they abandon it.

Check it out if you’re interested. Other podcasts I’ve done are listed here.

I’ve been asked this a couple of times, so perhaps it is worth a blog post.

For a simple training/test split, the Mean Absolute Scaled Error (MASE) (Hyndman & Koehler, 2006) is defined as and the Root Mean Squared Scaled Error (RMSSE) is defined as In both cases, for non-seasonal data, where is the seasonal period for seasonal data, and the sum in the numerator is over the test set, while the sum in the denominator is over the training set. The notation means the forecast of given data .

These measures are discussed in my forecasting textbook with George Athanasopoulos. The denominator is a scaling factor, introduced so that you can compare MASE or RMSSE values across series of different units. For example, are the forecasts of widget sales more accurate than the forecasts of electricity demand? If all your forecasts are in the same units, then you don’t need to remove the scale, and it is simpler to just use MAE or RMSE (i.e., only the numerators of the above equations).

Now, the question is, when we are doing time series cross-validation, and computing forecast accuracy over a series of training/test sets with a rolling origin, does it make sense to compute a different scaling factor each time? For example, a cross-validated MASE for -step forecasts is where the first observations form the smallest training set, and subsequent training sets increase one observation at a time.

An alternative approach would be to compute the scaling factor across all available data, rather than calculate it separately for each training set. Then MASE would become

Let’s think about the advantages of this alternative:

1. It is (slightly) faster. But the denominators are very fast to compute, so this really doesn’t make much difference.
2. It removes a source of variation from the calculation. The scaled errors will be more variable when the denominator changes with each test set, and that makes it harder to see the difference between forecasting methods.
3. It uses more data in computing the scaling factor, which reduces the uncertainty in the estimate of the accuracy measure. This is potentially important if , so that some training sets are relatively small compared to the available data.

As for disadvantages:

1. The measures are no longer true measures of forecast accuracy because the calculation potentially involves future observations. On the face of it, this seems important, but in reality it isn’t. The future observations aren’t affecting the forecasts, only the scaling factor, so there is no leakage involved.
2. One of my correspondents suggested that it changed the interpretation. I think the interpretability of these scaled measures is over-rated. They can only be interpreted as a ratio of out-of-sample accuracy to in-sample accuracy, and the two are not necessarily even over the same horizons. How the scaling factor is calculated doesn’t really affect the interpretation, because there is not much value in interpretation either way.

So I suggest that computing the scaling factor across all available training data when calculating cross-validated MASE and RMSSE values is a good idea.

That raises the question as to why shouldn’t we use all available data in the denominator when doing a simple training/test split? In that context, the only advantage that is relevant is #3 above, and unless the test set is particularly large, it shouldn’t make much difference. Nevertheless, I can’t see any real problem in using all available data in computing the scaling factor.

However, version 9.0 of the forecast package has now been released on CRAN. Thanks to Maximilian Muecke for helping with this release, and for modernising some of the old code.

Here are the main new features and changes.

USAccDeaths |> ets() |> forecast()
USAccDeaths |> auto.arima() |> forecast()

USAccDeaths |> snaive()

USAccDeaths |> rw_model(lag = 12) |> forecast()

library(purrr)
model_fns <- list(ets, auto.arima, rw_model, rw_model, mean_model)
args <- vector("list", length(model_fns))
args[[3]] <- list(lag = 12)
args[[4]] <- list(lag = 12, drift = TRUE)
models <- map2(model_fns, args, ~ do.call(.x, c(list(y=USAccDeaths), .y)))
names(models) <- map(models, function(u) u$method)
forecasts <- map(models, forecast)

The WAPE was introduced by Kolassa & Schütz (2007) who called it the MAD/Mean ratio. It is defined as where

• is the actual value at time ,
• is the forecast value at time

You can think of it as a weighted percentage error by writing it as where the weights are given by

It can also be considered a relative MAE where the comparison method has all forecasts equal to zero. In fact, would give the skill score relative to the forecast of zero for all .

Or you could think of it as like a MASE (Hyndman & Koehler, 2006) but with scaling based on the sum of absolute values on the test set rather than the sum of absolute differences on the training set.

This has some obvious advantages over the MAPE:

1. The MAPE is undefined when any actual value in the test set is zero. The WAPE is defined even when some actuals are zero. It is only undefined when all the actuals used in the denominator are zero.
2. Optimising the MAPE does not lead to a sensible point forecasts (Gneiting, 2011), but optimising the WAPE will lead to the median forecast.

However, I think there are a couple of problems that do not seem to have been widely recognized.

1. The resulting estimate is only consistent when the time series is stationary. So it should not be used with data that has trends, or seasonality, or heteroscedasticity.
2. It is quite possible to have all actuals in the test set equal to zero, especially with intermittent demand time series and small test sets. Then the denominator is zero, and the WAPE is undefined.

For these reasons, I think the Mean Absolute Scaled Error (MASE) (Hyndman & Koehler, 2006) is a better choice than the WAPE. The MASE is defined as where for non-seasonal data, and is the seasonal period for seasonal data, and the sum in the numerator is over the test set (of size ), and the sum in the denominator is over the training set (of size ). Because the denominator is defined on the training data, not the test data, it avoids the above problems with the WAPE:

• It is a consistent estimator provided the series is difference stationary, which is a much weaker condition than stationarity.
• The training data is also usually much longer than the test data, so it is much less likely to contain only zeros. In fact, if the training data did contain only zeros, then the obvious forecasts would all be zeros too.

I don’t want to suggest there are no problems with the MASE. Kolassa & Schütz (2007) point out one potential drawback of MASE — when there are structural breaks or outliers in the training data. Also, like the WAPE, optimising the MASE will lead to the median forecast, which is probably not what you want, especially when you have intermittent demand time series.

These days, if I want a scale-free accuracy measure, I prefer the Root Mean Squared Scaled Error (RMSSE): where again the sum in the numerator is over the test set, and the sum in the denominator is over the training set. This has all the advantages (and most disadvantages) of the MASE, but optimising it leads to the mean forecast rather than the median. It also aligns better with how models are estimated. Almost all models are estimated by minimising the sum of squared errors, so it makes sense to evaluate them using squared errors as well.

Point forecast reconciliation also works on means rather than medians, and is optimised using least squares, so it is more natural to evaluate using a squared error measure.

The fpp3 package is a companion to the book Forecasting: Principles and Practice (3rd edition, Hyndman & Athanasopoulos, OTexts). When you load the package, it loads the data and functions needed for the examples in the book.

library(fpp3)

── Attaching packages ──────────────────────────────────────────── fpp3 1.0.0 ──

✔ tibble      3.2.1     ✔ tsibble     1.1.4
✔ dplyr       1.1.4     ✔ tsibbledata 0.4.1
✔ tidyr       1.3.1     ✔ feasts      0.3.2
✔ lubridate   1.9.3     ✔ fable       0.3.4
✔ ggplot2     3.5.1     ✔ fabletools  0.4.2

── Conflicts ───────────────────────────────────────────────── fpp3_conflicts ──
✖ lubridate::date()    masks base::date()
✖ dplyr::filter()      masks stats::filter()
✖ tsibble::intersect() masks base::intersect()
✖ tsibble::interval()  masks lubridate::interval()
✖ dplyr::lag()         masks stats::lag()
✖ tsibble::setdiff()   masks base::setdiff()
✖ tsibble::union()     masks base::union()

This provides a shorthand way of attaching the packages needed for most time series forecasting tasks, using packages from the tidyverts, just as the tidyverse package does for data manipulation and visualization.

In the most recent update, we have added many new data sets that can be used as examples by instructors, or for users to practice their forecasting skills.

Each of these new data sets were previously used in an exam for the forecasting subjects taught by George Athanasopoulos and me at Monash University. Three of our exams are available online for those who are interested to see how we assess forecasting students.

• 2021
• 2022
• 2023

Each year, we take a new data set, and write the exam around how to analyse the time series. We strongly believe in assessing students on their forecasting skills with real data, rather than using artificial data, or asking technical questions that are not relevant to real-world forecasting. As a result, our exams are quite different from anything we have seen elsewhere.

We also think it is best to use “fresh and local”¹ data sets. So the data are almost always from Australia, and included data up to about a month before the exam was written.

In the latest update to the fpp3 package, we have expanded these data sets to cover more series than we did in the exams, and in most cases updated them to include more recent observations.

The new data sets are:

• aus_births: Australian births data
• aus_fertility: Australian fertility rates
• aus_inbound: Monthly short term (<1 year) visitor arrivals to Australia
• aus_migration: Australian migration data
• aus_mortality: Australian mortality data
• aus_outbound: Monthly short term (<1 year) resident departures in Australia
• aus_tobacco: Australian cigarette and tobacco expenditure
• aus_vehicle_sales: Australian vehicle sales
• melb_walkers: Average daily total pedestrian count in Melbourne
• nsw_offences: Monthly offences in NSW
• ny_childcare: New York childcare data
• otexts_views: OTexts page views

Thanks to Nuwani Palihawadana and Shanika Wickramasuriya for most of the work on this latest update, completed at the NUMBAT hackathon last month.

I get this question a lot, so I thought it might help to explain some issues with AIC calculation.

First, the equation for the AIC is given by where is the likelihood of the model and is the number of parameters that are estimated (including the error variance). For a linear regression model with iid errors, fitted to observations, the log-likelihood can be written as where is the residual for the th observation. The AIC is then Since we don’t know , we estimate it using the mean squared error (the maximum likelihood estimator), giving where is a constant that depends only on the sample size and not on the model. This constant is often ignored. Thus, different software implementations can lead to different AIC values for the same model, since they may include or exclude the constant .

Now, let’s look at what R returns in a simple case using the lm() function.

set.seed(2023)
library(fpp3)
df <- tibble(
  time = seq(100),
  x = rnorm(100),
  y = x + rnorm(100)
)
fit <- lm(y ~ x, data = df)
AIC(fit)

[1] 275.6267

We can check how this is calculated by computing it ourselves.

mse <- mean(residuals(fit)^2)
n <- length(residuals(fit))
k <- length(fit$coefficients) + 1
# With constant
2*k + n*log(mse) + n*log(2*pi) + n

[1] 275.6267

# Without constant
2*k + n*log(mse)

[1] -8.161047

Clearly, AIC() applied to the output from lm() is using the version with the constant.

Now compare that with what we obtain using the TSLM() function from the fable package.

df |>
  as_tsibble(index = time) |>
  model(TSLM(y ~ x)) |>
  glance() |>
  pull(AIC)

[1] -8.161047

This is the AIC without the constant.

The situation is even more confusing with ARIMA models, and some other model classes, because some functions use approximations to the likelihood, rather than the exact likelihood.

Thus, AIC values can be compared across models fitted using the same functions, but not necessarily when models have been fitted using different functions.

I received this email today:

My team recently used some techniques found in your writings to perform forecasts … Our work has been well received by reviewers, but one commenter asked two questions that I was hoping you may be able to provide insight on.

First, they wanted to know if we could provide P-values for our prediction intervals. In our work, we said, “Observed rates were deemed significantly different from expected rates when they did not fall within the 95% PI.” This same language has been used by others published in the same journal. I am curious to hear your thoughts on giving P-values for these PIs and what the appropriate method for doing so would be (if any).

Second, they asked about making a correction for multiple comparisons. … I believe we could apply a Bonferroni correction to the PIs, but that feels too liberal. Moreover, I am curious if this is even called for given our statement of what is deemed significant and the fact that our prediction interval construction relies on a non-parametric method.

Here is my reply:

1. I don’t think this makes any sense. A p-value is the probability of obtaining observations at least as extreme as those observed given a null hypothesis. What’s the hypothesis here? In forecasting, we don’t usually have a hypothesis. Instead, we fit a model to the data, and make predictions based on the model. I guess you could make the null hypothesis “The future observations come from the forecast distributions”, and then the p-value for each future time period would be the probability of the tails beyond the observations. But it is well-known that the estimated prediction intervals are almost always too narrow due to them not taking into account all sources of variance. So the size of this test would not be well-calibrated. I think you’re better off pushing back rather than trying to meet the request.

2. A Bonferroni correction assumes independence between the intervals, and that is not true for PIs from a forecasting model. The future forecast errors are all correlated (with the strength of the correlation depending on the model and the DGP). Usually we just say that these are pointwise PI, and so we expect 5% of observations to fall outside the 95% prediction intervals. It is possible to generate uniform PI, which contain 95% of all future sample paths, but this is a little tricky due to the correlations between horizons. It could be done via simulation – simulate a 1000 future sample paths and compute the envelope that contains 950 of them.

It sounds like the reviewers are only familiar with inferential statistics, and not with predictive modelling. You could point them to Shmueli’s excellent 2010 paper “To explain or predict”, highlighting the differences between the two paradigms.

There is a widespread myth that NASA did not discover the hole in the ozone layer above the Antarctic because they had been throwing away anomalous data that would have revealed it. This is not true, but the real story is also instructive (Pukelsheim 1990; Christie 2001, 2004).

NASA had been collecting satellite data on Antarctic ozone levels using a Total Ozone Mapping Spectrometer (TOMS) since 1979, while British scientists had collected ozone data using ground sensors at the Halley Research Station, on the edge of the Brunt Ice Shelf in Antarctica, since 1957. Figure 1 shows average daily values from the NASA measurements in blue, and from the British observations in orange. There is a clear downward trend in the British data, especially from the late 1970s, which is confirmed with the NASA data. So why wasn’t the “ozone hole” discovered until 1985?

The British scientists had noticed the low ozone values as early as 1981, but it took a few years for the scientists to be convinced that the low values were real and not due to instrument problems, and then there were the usual publication delays. Eventually, the results were published in Farman et al. (1985).

Meanwhile, NASA was flagging observations as anomalous when they were below 180 DU (shown as a horizontal line in Figure 1). As is clear from the figure, this is much lower than any of the plotted points before the early 1980s. However, the 180 threshold was used for the daily measurements, which are much more variable than the monthly averages that are plotted. Occasionally daily observations did fall below 180, and so it was a reasonable threshold for the purpose of identifying instrument problems.

In fact, NASA had checked the unusually low TOMS values obtained before 1985 by comparing them against other available data. But the other data available to them showed ozone values of about 300 DU, so it was assumed that the satellite sensor was malfunctioning. The British Halley data were not available to them, and only after the publication of Farman et al. (1985) did the NASA scientists realise that the TOMS results were accurate.

In 1986, NASA scientists were able to confirm the British finding, also demonstrating that the ozone hole was widespread across the Antarctic (Stolarski et al. 1986).

This example reveals some lessons about anomaly detection:

• The NASA threshold of 180 was based on daily data, and was designed to identify instrument problems, not genuine systematic changes in ozone levels. The implicit assumption was that ozone levels varied seasonally, but that otherwise the distribution of observations was stable. All anomaly detection involves some implicit assumptions like this, and it is well to be aware of them.
• Sometimes what we think are anomalies are not really anomalies, but the result of incorrect assumptions.
• Often smoothing or averaging data will help to reveal issues that are not so obvious from the original data. This reduces the variation in the data, and allows more systematic variation to be uncovered.
• Always plot the data. In this case, a graph such as Figure 1 would have revealed the problem in the late 1970s, but it seems no-one was producing plots like this.

References

Christie, M. 2001. The Ozone Layer: A Philosophy of Science Perspective. Cambridge University Press.

Christie, M. 2004. “Data Collection and the Ozone Hole: Too Much of a Good Thing?” History of Meteorology 1: 99–105.

Farman, J C, B G Gardiner, and J D Shanklin. 1985. “Large Losses of Total Ozone in Antarctica Reveal Seasonal ClO/NO Interaction.” Nature 315 (6016): 207–10.

Pukelsheim, F. 1990. “Robustness of Statistical Gossip and the Antarctic Ozone Hole.” The IMS Bulletin 19 (4): 540–45.

Stolarski, R S, A J Krueger, M R Schoeberl, R D McPeters, P A Newman, and J C Alpert. 1986. “Nimbus 7 Satellite Measurements of the Springtime Antarctic Ozone Decrease.” Nature 322 (6082): 808–11.

This question arises most time I teach a forecasting workshop, and it was raised again in the following email I received today:

I have a time series that I have split into training and test datasets with an 80%-20% ratio. I fit a series of different models (ETS, BATS, ARIMA, NN etc) to the training data and generate my forecasts from each model. When evaluating the forecasts against the test set I find the model that gives the best outcome is an ARIMA(1,1,1) that was selected using the auto.arima function. My question is this, should I proceed to fit an ARIMA(1,1,1) to the whole data set, or should I use the auto.arima function again which may give me a slightly different (p,d,q) order as there is now an extra 20% of unseen data available to the forecast model? Any guidance would be greatly received.

If you only have one class of model to consider (e.g., only ETS or only ARIMA), then it is easy enough to select the model on all available data using the AIC, and use the selected model to forecast the future. But if you are selecting between model classes, then you need to use either a training/test split, or (preferably) a time-series cross-validation procedure.

If you use time-series cross-validation, then there would usually be different models selected for each training set, and the cross-validated error is a measure of how well the model class works for your data. In that case, there is no single model for the training data, and you are selecting the model class rather than a specific model. This makes it clear that you should then apply the selected model class to all the data, when forecasting beyond the end of the available data. In other words, if you choose ARIMA over ETS, then you would then fit an ARIMA model to all the data, and use that model to forecast the future.

You can think of a simple training/test split as a special case of time-series cross-validation, where there is a single fold. So the same argument applies. That is, you are selecting the model class that works best for your data, and so you should apply that model class to all the data, when forecasting beyond the end of the available data.

This example also illustrates why it is important to use a time-series cross-validation procedure, rather than a simple training/test split. In this case, the ARIMA model was selected because it happened to work best for the particular training/test split that was used. But if a different split had been used, then a different model might have been selected. So the model selection is not stable. By averaging over multiple folds using a time-series cross-validation procedure, you can get a more stable estimate of the model class that works best for your data.

We have taught from the book many times, but this year we decided to pre-record short videos for each section. Our students often prefer a video explanation than reading the textbook, and we thought other readers might appreciate hearing from us as well.

These videos are embedded in most sections of the book. So far, we’ve covered the sections that we include in our own courses, but we hope to eventually have videos for all sections. Most of these were done in a single take, so they are sometimes a little rough, but hopefully still useful.

You can view the entire playlist on YouTube.

Places are limited, so please book in early.

• New York, 11-12 July 2023. Followed by the New York R conference. (Register for the workshop as part of the NYR conference registration.)
• Chicago, 17-18 September 2023. Followed by the Posit conference. (Register for the workshop as part of the Posit conference registration.)

The workshop introduces the tidyverts set of packages. Further details about the workshop are here.