Getting Your Data Into Shape
The first thing that will slow you down is not the modeling itself. It is getting the raw data into S-Plus in a format it will actually accept without throwing errors at you mid-run. I spent three days fighting with logreturns() on a daily returns object because the input vector had embedded NA values between legitimate observations. The function quietly dropped the gaps, shifted the index, and gave me a time series that looked correct until I tried to forecast it. The workaround was straightforward: I wrote a quick wrapper that flagged and removed any NA before passing the data to the fitting routine. You need to decide early whether you are working with prices, log-returns, or raw returns. They give different answers. Log-returns are additive across time and they behave better in GARCH models. Raw returns will make your likelihood surface messy and your optimizer will wander. If you are pulling data from a Bloomberg terminal or a CSV feed, check the timestamps. S-Plus handles regular intervals cleanly. Anything irregular needs to be resampled or modeled with state-space methods, and that is where things get complicated fast.
Modeling Financial Time Series With S Plus
When people talk about S-Plus for financial work, they are usually referring to the era before R fully took over. The core advantage was the S-Plus Financial Services Library and the built-in tseries and FinTS packages that handled ARIMA, GARCH, and cointegration tests. The syntax mirrors S language conventions, which means if you are transitioning from older codebases, it is readable. It is not the easiest tool to pick up today, but it does the job for standard time series work. The real friction comes from the fact that S-Plus has not seen major updates in years. The package ecosystem is frozen. You will not find the modern versions of packages like rugarch or forecast running cleanly on current operating systems without patching. Most people who still use S-Plus do so because they have legacy code that works and changing it would mean rewriting months of validation. That is a valid reason. It is not a reason to pretend it is a great choice for a new project.
Building an ARIMA-GARCH Pipeline
The standard approach for modeling financial returns in S-Plus is a two-step pipeline. You fit an ARMA model to the mean equation first, extract the residuals, test them for conditional heteroskedasticity, and then fit a GARCH model to those residuals. Here is what that looks like in practice: Use auto.arima() or the manual arima() function with AIC comparison to nail down the p and q orders. The output gives you coefficient estimates and standard errors. Then run a Ljung-Box test on the squared residuals. If the p-value is below 0.05 at multiple lags, you have ARCH effects. That is your signal to move to GARCH. The GARCH fitting step uses garch()’ from the FinTS library. The default is GARCH(1,1), which covers most equity and FX return series. You pass the residuals from the ARMA step and let the optimizer run. The function returns sigma squared estimates, log-likelihood, and AIC. I usually compare GARCH(1,1) against GARCH(2,1) and EGARCH(1,1) to check for asymmetry. The likelihood ratio test tells you whether the extra parameters are worth it.
Get the Full Details
One specific problem I ran into that nobody warns you about: the GARCH optimizer in S-Plus defaults to a BFGS routine that assumes positive definite Hessians. When your series has a structural break, like a flash crash or an earnings announcement, the likelihood surface becomes irregular and the optimizer converges to a boundary solution where sigma squared hits zero. I solved it by wrapping the fit in a try() block, detecting non-finite sigma values, and then re-running with method = "BHHH" and tighter starting values for alpha and beta. It added about ten seconds per fit but saved me from accepting garbage parameter estimates silently.
Diagnostics That Actually Matter
Fitting the model is the easy part. Deciding whether it is useful is where most people skip ahead and lose money. The diagnostic checklist for financial time series in S-Plus is narrow. Most of the standard textbook diagnostics do not apply because financial returns violate the assumptions these tests rely on. First, check the standardized residuals for remaining ARCH effects. Run Box.test(residuals^2, type = "Ljung-Box") across lags 1 through 20. If significant autocorrelation remains, your GARCH specification is inadequate. Second, check the quantile-quantile plot of the standardized residuals against a t-distribution. Financial returns have fat tails. A normal assumption will understate your VaR. S-Plus does not have a built-in t-distribution QQ test, so I wrote a small function that compares the empirical quantiles against theoretical t-quantiles and plots the deviation. It took about twenty minutes to write and saved me from relying on visual judgment alone. Third and most important, backtest your model. Out-of-sample performance is the only metric that matters if you are using this for risk management or trading. I hold out the last 20 percent of the data, fit on the training window, and compare predicted volatility against realized volatility using RMSFE and Theil's U statistic. Models that look good in-sample routinely fail here. A GARCH(1,1) fitted on daily S&P data from 2000 to 2010 will look impressive. Fit it on the same data and predict 2020 to 2023, and the forecasts drift badly during regime shifts. This is not a bug in S-Plus. It is a feature of financial markets.
Practical Warnings Before You Start
S-Plus is not dead, but it is functionally dead for new work. The licensing is expensive if you can even find a license anymore. The documentation is from 2007. The community support is minimal. You will spend more time Googling error messages than you will spend modeling. If your goal is solid financial time series analysis, R with packages like rugarch, forecast, and vars gives you the same models with active maintenance, peer review, and examples you can verify. The transition is not painless if you have existing S-Plus code, but it is usually a matter of syntax translation rather than rethinking the entire pipeline. For people who must stay in S-Plus because of institutional constraints, the key takeaway is that the statistical foundations are sound. ARIMA, GARCH, and cointegration work the same way. The limitations are practical: no modern visualization tools, slow optimization on large datasets, and package stagnation. Expect to write your own diagnostic functions and validation scripts. That is the normal state of things when you are working with legacy software.
